Dívida Técnica: Identificando, Medindo e Monitorando
98
Universidade de São Paulo Instituto de Matemática e Estatística Dívida Técnica: Identificando, Medindo e Monitorando Diogo de Jesus Pina Orientador: Prof. Dr. Alfredo Goldman Trabalho de Conclusão de Curso Bacharelado em Ciência da Computação http://linux.ime.usp.br/~diogojpina/mac499/ São Paulo 2013
Transcript of Dívida Técnica: Identificando, Medindo e Monitorando
Universidade de São Paulo
Instituto de Matemática e Estatística
Dívida Técnica:
Identificando, Medindo e
Monitorando
Diogo de Jesus Pina
Orientador: Prof. Dr. Alfredo Goldman
Trabalho de Conclusão de Curso
Bacharelado em Ciência da Computação
http://linux.ime.usp.br/~diogojpina/mac499/
São Paulo
2013
i
Resumo
Dívida técnica é uma metáfora criada em 1992 por Ward Cunnigham (criador da
Wiki), que o fez de maneira superficial e sutil, mas que ao passar dos anos vem
gerando discussões e pesquisas.
Atualmente, uma definição utilizada para a dívida técnica é a criada por Carolyn
Seaman e Yuepo Guo em Mensuring and Monitoring Technical [1]. Neste texto, dívida
técnica é definida como uma metáfora para artefatos imaturos, incompletos ou
inadequados no ciclo de vida de desenvolvimento de software.
Adquirir uma dívida técnica traz benefícios [2] a curto prazo, tais como redução
do tempo de desenvolvimento ou esforço. Mas, por outro lado, pode causar maiores
custos e menor qualidade a longo prazo.
Gerentes de software precisam equilibrar os benefícios da dívida técnica com os
custos associados à tomada de decisão de adquirir ou pagar a dívida técnica e quando.
A incerteza associada à dívida técnica torna a tomada de decisão ainda mais
complexa. Portanto, identificação, medida e monitoramento da dívida técnica podem
ajudar os gerentes a terem informações para a tomada de decisão. Isto resultaria em
maior visibilidade, o que pode melhorar a qualidade e produtividade na manutenção do
software.
Este projeto se dedica a encontrar ferramentas, técnicas e mecanismos que
viabilizem a identificação, medida e monitoramento da dívida técnica em projetos de
software. Estes artifícios poderão ajudar na criação de modelos que possibilitem uma
análise eficaz e eficiente e, consequentemente, a criação de uma teoria mais sólida.
ii
Abstract
Technical debt is a metaphor created at 1992 by Ward Cunningham (Wiki’s
creator) that made it in a superficial and subtle way, but over the year it has generated
discussion and research.
Currently, a good definition for technical debt was created by Carolyn Seaman
and Yuepo Guo at Mensuring and Monitoring Technical [1]. In this text, technical debt is
defined as a metaphor for immature, incomplete or unapproprieted artefacts in the
development life cycle of software.
Acquire a technical debt may be beneficial [2] in the short term in order to reduce
development time or required effort. But, it can cause higher costs and lower quality in
long term.
Software managers need to balance the benefits of technical debt with the
associated costs in taking decisions to acquire or pay the technical debt and when to
make it. The uncertainty associated to technical debt complicates this decision.
Therefore, the identification, measurement and monitoring of technical debt help
managers to have information for decision making. This would result in enhanced
visibility, which can improve quality and productivity in the maintenance of software.
This project is dedicated to finding tools, techniques and mechanisms that enable
the identification, measurement and monitoring of technical debt in software projects.
These devices can assist in creating models that enable effective and efficient analysis
and, consequently, the creation of a stronger theory.
iii
Parte I Técnica:
Introdução .................................................................................................................................. 2
1.1. Dívida Técnica ................................................................................................................. 2
1.2. Motivação ........................................................................................................................ 2
1.3. Objetivos ......................................................................................................................... 3
Conceitos e Tecnologias ............................................................................................................ 4
2.1. Dívida Técnica ................................................................................................................. 4
2.1.1. O que é Dívida Técnica? ........................................................................................... 4
2.1.2. Classificação de Dívida Técnica ................................................................................ 5
2.1.2.1. Dívida Técnica sem Intenção .............................................................................. 5
2.1.2.2. Dívida Técnica Intencional .................................................................................. 6
2.1.2.3. Dívida Técnica a Curto Prazo ............................................................................. 6
2.1.2.4. Dívida Técnica a Longo Prazo ............................................................................ 7
2.1.3. Cuidado Com a Dívida Técnica ................................................................................. 8
2.1.4. Exemplo de Custo para a Decisão de Adquirir Dívida Técnica .................................. 9
2.2. Modelos de Qualidade e Dívida Técnica.........................................................................10
2.2.1. Arcabouço para o Desenvolvimento de Modelos de Qualidade ................................10
2.2.1.1. O Nível de Tipo de Qualidade ............................................................................11
2.2.1.2. O Nível de Características .................................................................................11
2.2.1.3. O Nível de Subcaracterísticas ...........................................................................12
2.2.1.4. O Nível de Propriedades de Qualidade ..............................................................12
2.2.2. Modelos de Qualidade .............................................................................................12
2.2.2.1. Modelo de Qualidade em Uso ...........................................................................12
2.2.2.2. Modelo de Qualidade de Produto ......................................................................13
2.2.2.3. Outros Modelos de Qualidade ...........................................................................14
2.2.3. Dívida Técnica e Modelos de Qualidade ..................................................................14
2.3. Identificando Dívida Técnica ...........................................................................................15
2.3.1. Indicadores Diários de Dívida Técnica .....................................................................15
2.3.2. Ferramentas para Identificação de Dívida Técnica em Código-Fonte ......................16
2.4. Medindo Dívida Técnica .................................................................................................16
2.4.1. Função de Remediação ...........................................................................................16
2.4.2. Armazenando um Item de Dívida Técnica ................................................................17
iv
2.4.3. Cálculo do Custo da Dívida Técnica .........................................................................18
2.5. Monitorando Dívida Técnica ...........................................................................................19
2.5.1. Monitoramento Imediato da Dívida Técnica .............................................................20
2.5.2. Monitoramento ao Longo do Tempo .........................................................................20
Análise de Métodos e Ferramentas ...........................................................................................21
3.1. Métodos de Identificação ................................................................................................21
3.1.1. Análise (de código) Estática Automática ..................................................................21
3.1.2. Code Smells .............................................................................................................22
3.1.3. Padrões de Design e Grime .....................................................................................23
3.1.4. Violações de Modularidade ......................................................................................23
3.1.5. Testes ......................................................................................................................24
3.2. Métodos de Medida ........................................................................................................25
3.2.1. Calculando a Dívida Técnica ....................................................................................25
3.2.2. Agrupando a Dívida Técnica ....................................................................................26
3.2.3. Dimensionando a Dívida Técnica .............................................................................26
3.2.2. Representações da Medida de Dívida Técnica ........................................................27
3.2.2.1. A Escala do SQALE ...........................................................................................27
3.2.2.2. Kiviat..................................................................................................................28
3.2.2.3. Pirâmide SQALE ...............................................................................................29
3.3. Métodos de Monitoramento ............................................................................................30
3.3.1. Métodos de Monitoramento da Dívida Técnica ........................................................31
3.4. Ferramentas ...................................................................................................................35
3.4.1. FindBugs ..................................................................................................................35
3.4.2. Code Vizard .............................................................................................................36
3.4.3. Marple ......................................................................................................................37
3.4.4. CodeRush ................................................................................................................39
3.4.5. ReSharper ................................................................................................................40
3.4.6. Gendarme ................................................................................................................42
3.4.7. FxCop ......................................................................................................................43
3.4.8. CLIO ........................................................................................................................44
3.4.9. Junit .........................................................................................................................46
3.4.10. Eclemma ................................................................................................................48
3.4.1. Sonar Qube ..............................................................................................................49
v
3.4.12. Sonar Qube – Plugin Techinical Debt Evalutaion (SQALE) ....................................53
Resultado da Aplicação em Projetos de Software Livre ............................................................57
4.1. Análise Preliminar ...........................................................................................................57
4.2. Aplicação em Projetos de Software Livre........................................................................59
4.2.1. Eclemma ..................................................................................................................59
4.2.2. JDK 7 .......................................................................................................................62
4.2.3. PHP CodeSniffer ......................................................................................................64
4.2.4. Sonar Qube ..............................................................................................................66
4.2.5. Source Forge ...........................................................................................................69
4.2.6. Paul Grifts’ C Programming Examples .....................................................................72
4.2.7. Google Code ............................................................................................................74
4.3. Resultados das Aplicações .............................................................................................76
4.4. Resultados Finais ...........................................................................................................78
Conclusão .................................................................................................................................79
5.1. Perspectivas Futuras ......................................................................................................80
Referências Bibliográficas .........................................................................................................81
Parte II Subjetiva:
Análise Subjetiva ......................................................................................................................85
7.1. Trabalho de Formatura Supervisionado ..........................................................................85
7.1.1. Desafios e Frustrações ............................................................................................86
7.1.2. Aplicação .................................................................................................................86
7.1.3. Perspectivas Futuras ...............................................................................................86
7.2. BCC / IME-USP ..............................................................................................................87
7.2.1. Disciplinas ................................................................................................................87
1
Parte I Técnica
2
Capítulo 1
Introdução
Este trabalho fará um estudo sobre os conceitos relacionados à dívida técnica.
Em especial, serão analisados métodos para identificação, medida e monitoramento da
dívida técnica.
Além disso, serão feitas aplicações dos métodos em projetos de software livre a
fim de possibilitar uma análise da dívida técnica nestes projetos. E, por fim, fazer
comparações entre eles.
1.1. Dívida Técnica
Apesar de sua primeira abordagem tem sido feita por Ward Cunningham em
1992, somente nos últimos anos que ela vem ganhando destaque, não só na
comunidade científica, mas também nas empresas.
As pesquisas ainda estão em fase de desenvolvimento, precisando que mais
trabalhos sejam realizados para se construir uma base e permitir que seus conceitos
possam ser usados facilmente pelos grupos de desenvolvimento e pesquisa.
Em termos práticos, existem diversas ferramentas, para diversas linguagens de
programação, que podem ser utilizadas para identificar a dívida técnica, porém poucas
são realmente apropriadas para isso. Além disso, foi encontrada apenas uma
ferramenta que é capaz de realizar a medida e o monitoramento da dívida técnica.
Em termos acadêmicos, a dívida técnica pode ser enquadrada como uma
subárea de qualidade de software que, por sua vez, é uma subárea de engenharia de
software. Portanto, ela pode utilizar os muitos trabalhos desenvolvidos nestas áreas
para seu próprio desenvolvimento.
1.2. Motivação
A motivação principal para este trabalho é o controle da dívida técnica, que,
muitas vezes, é importante para garantir a sobrevivência de um projeto de software.
Isso desperta o interesse tanto da comunidade acadêmica, quanto de empresas e
grupos de desenvolvimento de software livre.
3
Além disso, como ela pode ser dada em horas de trabalho, custo monetário ou
uma unidade simbólica, ela pode ser de interesse de vários grupos, desde os
programadores, passando pela gerência até chegar à diretoria. Pode até interessar
grupos externos tais como clientes e investidores, que a partir da medida da dívida
técnica podem acompanhar o desenvolvimento do projeto.
Outra motivação é o fato de que se têm poucos trabalhos nesta área, sendo
assim, este trabalho pode contribuir diretamente com pesquisas futuras. Além disso,
pessoas influentes da área de engenharia de software como Ward Cunningham e
Martin Fowler já motivaram e fizeram contribuições para a área.
Universidades importantes como a Universidade de São Paulo (USP) e
Universidade de Mayland Baltimore Country (UMBC) possuem pesquisadores
trabalhando em projetos nesta área, tendo apoio de empresas e centros de pesquisas.
1.3. Objetivos
O primeiro objetivo deste trabalho de formatura supervisionado é um estudo
detalhado sobre a metáfora de dívida técnica. Isto será feito com base em artigos
científicos publicados e trabalhos acadêmicos que ainda estão sendo desenvolvidos.
Este estudo permitirá um bom entendimento do conceito de dívida técnica e oferecerá
uma base para a pesquisa.
O segundo objetivo é encontrar ferramentas, técnicas e mecanismos que
viabilizem a identificação, medida e monitoramento da dívida técnica.
O terceiro objetivo é utilizar estes métodos e recursos para encontrar dívida
técnica em projetos de software livre. Com isso será possível fazer uma análise para
tentar identificar a relação entre o sucesso dos projetos e sua dívida técnica.
4
Capítulo 2
Conceitos e Tecnologias
2.1. Dívida Técnica
Neste capítulo serão apresentados os conceitos fundamentais envolvendo dívida
técnica. Dentre eles, explicações do que é a dívida técnica, classificações e alguns
exemplos práticos.
2.1.1. O que é Dívida Técnica?
Dívida técnica é uma metáfora criada em 1992 por Ward Cunningham (criador
da Wiki) que o fez de maneira superficial e sutil, mas que ao passar dos anos vem
gerando muita discussão e pesquisa. O trecho abaixo são as palavras de Cunningham,
a qual motivou toda a discussão. Nele está uma comparação entre o desenvolvimento
de código e dívida técnica, tal como na economia, expressando os perigos do não
pagamento da dívida técnica e da cobrança de juros.
“Shipping first time code is like going into debt. A little debt speeds development
so long as it is paid back promptly with a rewrite. Objects make the cost of this
transaction tolerable. The danger occurs when the debt is not repaid. Every minute
spent on not-quite-right code counts as interest on that debt [5].”
Atualmente uma das definições mais utilizadas para a dívida técnica é a criada
por Carolyn Seaman e Yuepo Guo em Mensuring and Monitoring Technical [1]. Neste
texto, dívida técnica é definida como uma metáfora para artefatos imaturos,
incompletos ou inadequados no ciclo de vida de desenvolvimento de software.
Adquirir a dívida técnica traz benefícios a curto prazo, tais como, redução do
tempo de desenvolvimento ou esforço, mas pode causar maiores custos e menor
qualidade a longo prazo.
Gerentes de software precisam equilibrar os benefícios da dívida técnica com os
custos associados na tomada de decisão de adquirir ou pagar a dívida técnica e
quando. A incerteza associada à dívida técnica torna a tomada de decisão mais
complexa. Portanto, a identificação, medida e monitoramento da dívida técnica
ajudariam os gerentes a terem informações para a tomada de decisão. Resultando,
5
assim, em maior visibilidade, o que pode melhorar a qualidade e produtividade na
manutenção do software.
Ainda hoje, a dívida técnica precisa de uma teoria base, modelos que
possibilitem sua análise, ferramentas e mecanismos que viabilizem sua identificação,
sua medida e seu monitoramento.
Como dívida técnica tem uma grande relação com dívida econômica, inclusive o
vocabulário, isso permite que até pessoas não técnicas como consultores, gerentes e
diretores entendam e possam acompanhar os problemas gerados pela dívida, dando a
importância necessária para o seu pagamento. Além disso, o fator dívida pode ser
fundamental para mostrar ao cliente a importância de manter a qualidade de código.
A dívida técnica só acontece em softwares que estão sendo implementados ou
já estão em produção. Projetos de softwares abandonados não acumulam mais
dívidas. Em alguns casos, as dívidas técnicas adquiridas ao decorrer destes projetos
são simplesmente anuladas. Em outros, a dívida técnica poderá estar atrelada não
somente a apenas um projeto, mas pode se espalhar para vários projetos ou afetar
diretamente o capital de investimento da instituição. Sendo assim, mesmo com o
encerramento do projeto a instituição terá que pagar pelo menos parte da dívida e dos
juros relacionados a ela.
2.1.2. Classificação de Dívida Técnica
Segundo McConnell [3] a dívida pode ser classificada em dois tipos dependendo
da maneira em que são adquiridos, estes tipos são: dívida técnica sem intenção e
dívida técnica intencional.
Sendo a dívida assumida de maneira intencional, McConnell também classifica a
dívida técnica em outros dois tipos, dependendo do tempo que elas levam para serem
pagas, estes tipos são: dívida técnica de curto prazo e dívida técnica de longo prazo.
2.1.2.1. Dívida Técnica sem Intenção
Ocorre quando a dívida é adquirida sem que a equipe perceba, ou seja, por
algum descuido ou devido à complexidade sejam introduzidos problemas ou não sejam
introduzidas boas soluções. Este tipo de dívida não é resultado de uma estratégia,
gerando assim, um impacto negativo.
6
Alguns exemplos do surgimento desta dívida são: “Um layout que não funciona
corretamente em uma determinada versão de um navegador específico”, “Inserção de
bad codes por programadores inexperientes”, “Um cliente pediu uma funcionalidade
para o sistema, porém a funcionalidade não foi totalmente detalhada e quando a
solução chega ao cliente não era exatamente o que ele esperava”.
Algumas analogias para este tipo de dívida são: “Bati meu carro, então depois
vou ter que mandar desamassar”, “Minha geladeira não está mais funcionando, preciso
mandar consertar”, “Comprei uma TV, porém esqueci que não tenho antena e nem
assinatura de uma TV a cabo.”.
2.1.2.2. Dívida Técnica Intencional
Ocorre quando a dívida técnica a ser adquirida já é conhecida e por algum
motivo a equipe decide adquiri-la de maneira consciente. Isso pode ocorrer para
acelerar o trabalho atual, deixando de lado os esforços futuros. Logo este tipo de dívida
é resultado de uma estratégia. Geralmente essa necessidade de se assumir a dívida
esta relacionada com o tempo, ou seja, a necessidade de entrega de um conjunto de
atividades num tempo menor do que o necessário para manter a qualidade.
Alguns exemplos do surgimento desta dívida técnica são: “Uma equipe não tem
tempo suficiente para unir estas duas bases de dados agora, então ela escreve um
código que mantém as duas bases sincronizadas e as junta depois que essa versão for
enviada.”, “Uma equipe tem um código que resolve o problema, porém este código não
esta nos padrões de códigos utilizados por ela, então se opta por usar este código e
deixa para depois a sua limpeza.”, “Uma equipe não teve tempo para escrever todos os
testes de unidade para os códigos escritos nos últimos dois meses. Então eles
liberaram a nova versão para depois escreverem estes testes.”.
Algumas analogias para este tipo de dívida técnica são: “Meu carro está com os
faróis queimados, vou usá-lo apenas durante o dia e quando receber meu salário
comprarei faróis novos e poderei novamente andar a noite.”, “Vou comprar televisão
menor, mas com assinatura de TV a cabo e quando tiver mais dinheiro a troco por uma
maior.” e “Vou comprar um carro, para isso, vou fazer um empréstimo no banco”.
2.1.2.3. Dívida Técnica a Curto Prazo
Bem como uma dívida comum a dívida técnica pode ser paga num curto prazo
e, geralmente, o pagamento deste tipo de dívida técnica é feito para suprir as
7
necessidades imediatas ou quando se tem dinheiro (mão-de-obra) extra. Outra
característica desse tipo de dívida é que ela é paga com certa frequência a fim de
reabilitar o crédito para aquisição de novas dívidas. As dívidas a curto prazo, em geral,
não necessitam de um grande planejamento, sendo adquiridas para suprir as
necessidades do momento e que não produzem um grande impacto.
Um exemplo de dívida a curto prazo é a cobertura de testes em grande parte do
código, que por motivo de falta de tempo, as vezes são deixadas de lado a fim de
manter o prazo de entrega do lançamento.
Algumas analogias para este tipo de dívida são: “Vou comprar pão todo dia e
mando anotar na caderneta e no final do mês pago.”, “Vou comprar um carro em 24
parcelas.” e “Vou abastecer meu carro apenas com o cartão de crédito, pois assim
pagarei apenas no dia de vencimento do cartão de crédito”.
2.1.2.4. Dívida Técnica a Longo Prazo
As dívidas técnicas a longo prazo são adquiridas, em geral, de forma
estratégica, com um planejamento a fim de suprir necessidades de grande impacto,
como por exemplo, o lançamento de um certo produto a fim de ganhar espaço no
mercado, adquirindo a dívida de implementação de novas funcionalidades, cobertura
de testes, falhas no sistema, falta de um suporte técnico adequado ou qualquer outra
necessidade técnica de grande porte, que no futuro precise ser paga.
Mesmo a dívida sendo a longo prazo, caso o gerente e/ou a equipe tenham
necessidade ela pode ser paga rapidamente, ou pode ser gerenciada durante anos.
Um exemplo de dívida técnica a longo prazo é a não refatoração de partes do
código e cobertura de testes, muitas vezes para implementar um grande número de
funcionalidades, num período menor de tempo. Logo a dívida fica a ser paga após a
implementação de todas as funcionalidades. Outro exemplo é a criação de um setor
específico para suporte de um determinado sistema.
Algumas analogias para este tipo de dívida são: “Preciso comprar uma casa
então vou pagar em 120 prestações.”, “Vou comprar um carro de luxo, para isso tenho
que fazer mais 80 prestações a mais do que se fosse comprar um carro popular.” e
“Vou contratar funcionários com um contrato mínimo de 5 anos.”.
8
2.1.3. Cuidado Com a Dívida Técnica
A dívida técnica mais perigosa que temos a priori é a sem intenção. Se a equipe
não utilizar de métodos e ferramentas para identificá-la e, em seguida, medi-la e
acompanhá-la, ela pode fazer um projeto ir à falência. A falência de um projeto significa
que ele deverá ser reescrito ou até mesmo abandonado. Qualquer um dos casos pode
gerar um grande volume de trabalho, uma perda de tempo e esforços ou até mesmo
criar um impacto financeiro muito grande.
Porém a dívida técnica intencional também pode ser perigosa caso não seja
medida de maneira adequada, não tenha um acompanhamento de sua evolução ou
não tenha um plano estratégico para realizar seu pagamento. Esses perigos valem
tanto para a dívida técnica de curto ou longo prazo, pois por causa dos juros a de curto
prazo pode se tornar uma de longo prazo, e a de longo prazo pode ficar inviável de
pagar, levando assim o projeto a falência.
Adquirir uma dívida técnica deve ser muito bem planejado, para evitar que esta
não seja paga e acumule juros excessivos. Portanto, a equipe deve levar em conta o
contexto, sua capacidade de pagar a dívida técnica, o tamanho da dívida e sua forma
de pagamento na hora de realizar uma aquisição.
O contexto em que o software é utilizado está diretamente ligado com a dívida
técnica. Podendo ser no aspecto de qual a dívida pode ser assumida, seu tempo de
pagamento e seu valor. Por exemplo, ao adquirir uma dívida na cobertura de testes de
um aplicativo web com pouco acesso, geralmente, implica em uma dívida baixa, pois
mesmo que o aplicativo tenha algum problema este problema não afetará de forma
significativa.
Além disso, pagar a dívida técnica pode ser feito de forma rápida e sem muito
custo. Já um aplicativo para avião se não tiver uma cobertura de testes ideal, poderá
acarretar em acidentes e consequentemente um grande prejuízo. Neste caso, o
pagamento da dívida técnica pode ser demorado e caro, pois trocar o software de cada
avião poderá demorar e ainda ter um custo alto tanto da equipe de manutenção. O fato
que o avião necessitará ficar fora de operação, também acarretará em prejuízos.
9
2.1.4. Exemplo de Custo para a Decisão de Adquirir Dívida Técnica
Suponha que seu cliente peça um software que necessite de um cadastro de
produtos completo, com cadastros de várias fotos e com campos para controle de
quantidade e deseja que este cadastro seja entregue em três dias.
Após uma análise por parte da equipe técnica, para criar o cadastro conforme a
solicitação do cliente e mantendo a qualidade do software seriam necessários cinco
dias, com o custo de desenvolvimento de $ 1.000.
Então surgem algumas opções para que o cadastro possa ser entregue:
1. Entregar sem dívida técnica
Para isso seria necessário convencer o cliente da importância de se manter a
qualidade do software e entregar o software em cinco dias ao invés de três.
Custo imediato $ 1.000,00.
2. Adquirir uma dívida técnica sem intenção
Fazer com a equipe técnica tente trabalhar com maior velocidade, o que poderá
acarretar em adquirir uma dívida técnica sem intenção, por causa de padrões ruins de
códigos, a inserção de erros e ações inesperadas e até mesmo a não cobertura
satisfatória nos testes.
Custo imediato $ 600,00
Custo da dívida $ 400,00
Custo dos Juros $ 500,00 (devido à dificuldade de identificar a dívida)
3. Adquirir uma dívida técnica intencional a curto prazo
Para adquirir uma dívida técnica a curto prazo, a equipe poderia abrir mão de
algumas funções como ter várias fotos por produtos e manter a cobertura de testes
apenas para as partes críticas e após a primeira entrega, pagá-la imediatamente.
Custo imediato $ 600,00
Custo da dívida $ 400,00
Custo dos Juros $ 40,00 (devido ao baixo tempo em dívida)
10
4. Adquirir uma dívida técnica intencional a longo prazo
É a mesma situação que a anterior só que a dívida técnica ao invés de ser paga
imediatamente, será paga apenas após o desenvolvimento do sistema completo,
demorando um tempo maior para ser paga.
Custo imediato $ 600,00
Custo da dívida $ 400,00
Custo dos Juros $ 200,00 (devido ao alto tempo em dívida sem pagamento)
2.2. Modelos de Qualidade e Dívida Técnica
Para que seja viável a identificação, medida e gerenciamento da dívida técnica
será utilizado o arcabouço para o desenvolvimento de modelos de qualidade proposto
pela ISO/IEC 25010:2011 [7].
Além disso, para definir melhor o modelo de qualidade de produto de software
será usada a parte da abordagem proposta em The SQALE Method [6]. Este modelo
será o principal modelo abordado neste trabalho, pois a partir dele é possível realizar a
automação dos métodos de identificação e consequentemente viabilizar o cálculo da
dívida técnica.
Tanto o método SQALE quanto a ISO/IEC 25010:2011 foram desenvolvidos
para avaliação da qualidade de software em geral, por isso, podem ser aplicados a
qualquer representação do software. Estas representações podem tanto ser código-
fonte, nosso principal objetivo, quanto documentações e diagramas, tais como o UML.
Esta organização com vários modelos de qualidade permite que a qualidade, e
logo a dívida técnica, possa ser analisada do ponto de vista de cada parte interessada.
Estas partes interessadas podem ser: clientes, investidores, gerentes de projeto,
analistas, programadores ou qualquer grupo que tenha interesse no software ou em
parte dele.
2.2.1. Arcabouço para o Desenvolvimento de Modelos de Qualidade
A ISO/IEC 25010:2011 propõe um arcabouço para a criação de modelos de
qualidade. Este arcabouço é desenhado em uma hierarquia de quatro níveis: tipo de
qualidade, características, subcaracterísticas e propriedades de qualidade, como
mostra a figura.
11
2.2.1.1. O Nível de Tipo de Qualidade
O nível de tipo de qualidade é definido de acordo com o que se deseja avaliar do
software. Geralmente, isto é definido de acordo com as partes interessadas. Para cada
parte interessada, ou para cada grupo de partes interessadas, é definido o tipo do
modelo e o que ele irá avaliar.
Alguns exemplos de tipo de qualidade são: qualidade do produto, qualidade de
dados e qualidade de uso.
2.2.1.2. O Nível de Características
O nível de características é definido de acordo com o tipo de qualidade que se
deseja avaliar. Estas características podem ser entendidas como habilidades do
sistema, ou seja, os principais pontos pelo qual o software possa ser avaliado.
Mesmo em modelos pré-definidos, poderão ser inseridas e/ou retiradas
características a fim de que o modelo possa expressar o contexto do software.
12
2.2.1.3. O Nível de Subcaracterísticas
Cada característica pode ser dividida em subcaracterísticas. As
subcaracterísticas são usadas para agrupar as propriedades de qualidade de maneira
que elas possam ser analisadas e ganhar um significado mais forte.
As subcaracterísticas correspondem aos ciclos de vida das atividades realizadas
durante o desenvolvimento do software.
Mesmo em modelos pré-definidos, poderão ser inseridas e/ou retiradas
subcaracterísticas a fim de que o modelo possa expressar o contexto do software.
2.2.1.4. O Nível de Propriedades de Qualidade
Este nível contém todas as propriedades relacionadas com a qualidade do
software. Para que estas propriedades sejam realmente significativas elas devem ser
formuladas com um grande rigor de qualidade.
Mesmo em modelos pré-definidos, poderão ser inseridas e/ou retiradas
propriedades de qualidade a fim de que o modelo possa expressar o contexto do
software.
2.2.2. Modelos de Qualidade
Modelos de qualidade são representações abstratas que servem para
armazenar organizar e gerenciar os problemas identificados com relação à qualidade.
Os modelos facilitam o trabalho de gerenciamento de qualidade permitindo tomadas de
decisões.
2.2.2.1. Modelo de Qualidade em Uso
O modelo de qualidade em uso é definido na ISO/IEC 25010:2011 com cinco
características que estão relacionadas com os efeitos da interação com o software.
Este modelo de qualidade permite avaliar o impacto do produto dentro do seu contexto
segundo a visão das partes interessadas.
As cinco características que são definidas neste modelo são: eficácia, eficiência,
satisfação, liberdade de risco e cobertura de contexto. Estas características podem ser
adaptadas de acordo com o grupo de partes interessadas.
13
Neste modelo, em geral, as propriedade de qualidade podem ser definidas como
requisitos não funcionais do software, permitindo uma avaliação externa da qualidade.
Ou seja, este modelo se baseia na satisfação dos usuários e no valor introduzido pelo
software.
2.2.2.2. Modelo de Qualidade de Produto
Este modelo é o mais importante para este trabalho, pois baseado nele é
possível identificar grande parte da dívida técnica com o auxílio de software.
A construção deste modelo ocorrerá pela união da descrição realizada na
ISO/IEC 25010:2011 e o texto The SQALE Method.
As características utilizadas para este modelo são: reuso, portabilidade,
manutenção, segurança, eficiência, usabilidade, confiabilidade e testabilidade. Estas
características podem ser adaptadas de acordo com o grupo de partes interessadas ou
de acordo com o contexto do software.
14
As subcaracterísticas deste modelo dependerão, estritamente, do contexto do
software. Por exemplo, software para aviação precisará de uma subcaracterística de
verificação formal dentro de testabilidade. Já um catálogo eletrônico não precisa deste
rigor, logo uma subcaracterística de validação pode ser suficiente.
Neste modelo, em geral, as propriedade de qualidade podem ser definidas como
requisitos funcionais do software, permitindo uma avaliação interna da qualidade. Ou
seja, este modelo se baseia na qualidade do código-fonte e das partes relacionadas.
Logo, com ele podemos encontrar grande parte da dívida técnica relacionada a código-
fonte.
2.2.2.3. Outros Modelos de Qualidade
Outros modelos de qualidade poderão ser desenvolvidos para que outros tipos
de qualidade possam, também, ser avaliados utilizando o mesmo arcabouço. Modelos
como o de qualidade de dados ou de alguma característica que precisa ser
rigorosamente explorada são exemplos destes novos modelos.
Porém estes novos modelos não serão o foco deste trabalho, pois, em geral, é
difícil automatizar a identificação.
2.2.3. Dívida Técnica e Modelos de Qualidade
Para cada propriedade de qualidade, diversos pontos podem ser encontrados.
Logo podemos verificar se cada um destes pontos está ou não em conformidade com a
propriedade. Estes pontos podem ser vistos, como possíveis pontos de dívida técnica.
Caso não esteja, é possível calcular o custo em horas ou dinheiro que seria
necessário investir para que este ponto respeite a propriedade, se sim, este custo seria
zero, pois não é preciso fazer nenhum tipo de esforço para pagá-lo.
A soma de todos estes custos seria o custo de tornar uma propriedade de
qualidade válida. Logo a soma destes custos é o custo de deixar todas as propriedades
de qualidade do projeto válidas e, isso pode ser visto como a quantidade de dívida
técnica do projeto.
15
2.3. Identificando Dívida Técnica
Com o objetivo de prevenir a dívida técnica e seu acúmulo, ou decidir quando,
onde e quanto pagar da dívida, o primeiro passo é identificá-la.
A dívida técnica externa está relacionada diretamente com as partes
interessadas, logo a sua identificação pode ser difícil e sua automação praticamente
inviável.
Já a dívida interna se relaciona diretamente as descrições do software, em
especial o código-fonte, sendo assim fica mais fácil detectá-la, principalmente
automaticamente. Além disso, a dívida técnica interna tem uma forte relação com a
externa. Sendo assim, quando se é paga uma dívida interna, indiretamente, pode se
estar pagando uma dívida externa, mesmo que esta não tenha sido explicitamente
identificada.
Para identificar a dívida técnica baseada em código-fonte (parte da dívida
interna) serão utilizados os métodos apresentados em Identifying and Managing
Technical Debt [8] e Comparing Four Approaches for Technical Debt Identification [9].
Uma destas técnicas são os indicadores diários de dívida técnica e a outra é o
uso de ferramentas.
Utilizando os modelos de qualidade podemos definir que encontrar uma dívida
técnica é encontrar uma violação de uma propriedade de qualidade. Como vamos lidar,
em particular, com o modelo de qualidade de produto, definimos que uma dívida
técnica é uma violação de um requisito funcional.
2.3.1. Indicadores Diários de Dívida Técnica
Os indicadores diários de dívida técnica são situações que ocorrem com a
equipe de desenvolvimento que indicam que o software possui dívida técnica. Estas
situações podem determinar dívidas técnicas pontuais e que, em geral, podem ser
encontradas facilmente. Mas também podem determinar dívidas técnicas genéricas,
onde pode se necessitar de horas ou até mesmo dias para que se possa identificá-las.
Exemplos de identificadores diários retirados de [8]:
● Não se preocupe com a documentação agora;
● O único que pode mudar este código é o João;
● Está bom para o momento, mas precisaremos refatorar mais tarde;
16
● To Do e FixMe no código-fonte;
● Vamos apenas copiar e colar esta parte;
● Quem sabe onde armazenamos a senha de acesso ao banco de dados;
● Eu sei, se eu tocar neste código ele quebrará e
● Vamos terminar os testes na próxima versão.
2.3.2. Ferramentas para Identificação de Dívida Técnica em Código-Fonte
O objetivo destas ferramentas é encontrar defeitos e falta de padrões no código-
fonte de forma automática. Esses elementos podem gerar dívida técnica, como
veremos mais adiante.
As ferramentas de identificação utilizam os seguintes métodos para encontrar os
defeitos: análise automática (de código) estática, code smells, padrões de design e
grime, violações de modularidade e testes. Estas ferramentas serão abordadas nos
próximos capítulos.
2.4. Medindo Dívida Técnica
Para que se possa realizar a medida da dívida técnica será utilizado o método
descrito em The SQALE Methos [6].
Este método consiste em um conjunto de regras que são utilizadas para
viabilizar e padronizar as medidas. Além disso, ele padroniza os controles relativos ao
código-fonte e as regras de agregações de valores.
Para que se possa fazer esta padronização será associada a cada propriedade
de qualidade uma função que chamaremos de função de remediação.
A partir das funções de remediação é possível calcular a dívida técnica, por
partes ou do software inteiro.
2.4.1. Função de Remediação
O objetivo da função de remediação é determinar o custo de sair do estado atual
para um estado desejado. Para cada propriedade de qualidade se tem uma função de
remediação, isso faz com que as medidas fiquem padronizadas.
A entrada dessa função é um indicador se a propriedade de qualidade foi
violada, ou não, e, caso existam, os valores associados a esta violação. Como saída se
17
tem um valor de custo, que pode ser um custo monetário, um custo em horas de
trabalho ou um custo simbólico.
Esta função pode ser dada por uma função simples que atribui 0, caso não
ocorra violação, e uma constante, caso ocorra. Outra possibilidade é definir um fator
multiplicativo para a violação de acordo com os valores associados a esta violação.
Esta função também pode ser dada por funções mais elaboradas, utilizando outras
funções, tais como as exponenciais, logarítmicas, trigonométricas ou quaisquer outras
funções que modelem de forma adequada o custo.
Exemplo: Suponha que a propriedade é: “Todo método deve estar coberto por
pelo menos um teste de unidade”. Vamos definir a função de remediação como sendo:
f(x, y) = x ln (y), onde x é 0, caso o método esteja coberto, e 1, caso não; e y a
quantidade de linhas de cada método. A função f(x, y) devolverá o custo em horas para
que o método seja coberto.
É importante observar que toda função de remediação deverá ser 0, caso não
haja violação da propriedade de qualidade.
2.4.2. Armazenando um Item de Dívida Técnica
Para ajudar na organização e na automação do cálculo da dívida técnica será
criada uma estrutura de dados parecida com a proposta em Measuring and Monitoring
Technical Debt [10]. A estrutura será adequada ao modelo que está sendo utilizado.
ID 42
Data - Hora 01/06/13 - 11:30:34
Propriedade de Qualidade Todo método deve estar coberto por pelo menos um teste de unidade.
Local Classe ABC : Método XYZ
Custo de Remediação 2,5 horas
Prioridade para Pagamento Alto
18
2.4.3. Cálculo do Custo da Dívida Técnica
Para que se possa calcular a dívida técnica do software com exatidão é preciso
que:
- Todos os tipos de qualidade sejam independentes;
- Todas as características do modelo devem ser independentes;
- Todas as subcaracterísticas do modelo devem ser independentes;
- Todas as propriedades de qualidade do modelo devem ser independentes;
- A partir das propriedades de qualidade, todos os custos de dívida técnica
devem ser encontrados.
As regras acima, na prática, são difíceis de serem cumpridas. Logo, para que o
cálculo seja viável, podemos calcular parte da dívida técnica de uma dada propriedade
de qualidade, subcaracterística, característica ou tipo de qualidade que atenda aos
requisitos.
Caso não seja possível garantir independência e/ou que toda dívida técnica seja
encontrada teremos:
- Limitante superior: caso se possa encontrar toda dívida técnica, mas não se
possa garantir independência. Isso ocorre devido a intersecção entre os itens, fazendo
com que os custos sejam somados mais de uma vez;
- Aproximação: caso não se possa garantir a independência, nem que toda
dívida técnica seja encontrada. Isso pode ser ruim, pois pode aparecer uma grande
dívida técnica, devido ao acúmulo repetido de itens, ou uma dívida técnica pequena,
devido ao fato de não conseguir encontrá-la.
O cálculo da dívida técnica pode ser feita em vários níveis, desde o mais baixo
com as propriedades de qualidade até o mais alto, calculando a dívida do software
como um todo. Ou seja, podem ser agrupados, em diversos níveis, criando assim
índices de dívida técnica.
Os índices de dívida técnica padronizam a soma de diversas medidas em um
conjunto que faça sentido, ou seja, importante para determinadas partes de interesse.
19
2.5. Monitorando Dívida Técnica
O objetivo de identificar e medir a dívida técnica é viabilizar e facilitar as
tomadas de decisões [10]. Este conjunto que consiste de identificar, medir e tomar
decisões, nesta ordem, gerando e se baseando em uma lista de dívida técnica, junto
com os procedimentos será o arcabouço utilizado para o gerenciamento da dívida
técnica.
O monitoramento da dívida técnica pode ser feito de duas maneiras. A primeira
é de forma imediata e a segunda a longo do tempo.
Além da dívida técnica explícita na lista de dívida técnica, é possível utilizar o
monitoramento a fim de encontrar dívidas implícitas [11]. Algumas técnicas serão
exibidas e explicadas em capítulos posteriores.
Os índices de dívida técnica são grandes auxiliadores do monitoramento. Eles
permitem com que determinadas partes, geralmente as partes críticas ou importantes
para alguma parte interessada, possam ser monitoradas de maneira fácil.
20
2.5.1. Monitoramento Imediato da Dívida Técnica
Após serem identificadas as dívidas técnicas de interesse e ao se processar
com as funções de remediação para se obterem as medidas para todos os pontos de
dívida técnica, se chega a uma lista de dívida técnica.
O monitoramento imediato da dívida técnica consiste em realizar o processo
descrito acima e analisar a dívida técnica a fim de tomar decisões. Este monitoramento
permite verificar os pontos com maiores problemas de dívida técnica, ou seja, pontos
onde exista uma quantidade considerável de dívida técnica que tenham um alto
interesse no pagamento.
No monitoramento imediato os índices são essenciais para a tomada de
decisão, pois eles permitem verificar de forma fácil a quantidade de dívida técnica em
determinado ponto.
2.5.2. Monitoramento ao Longo do Tempo
O monitoramento ao longo do tempo consiste em reunir as listas das dívidas
técnicas de diferentes datas a fim de monitorá-las em diversos aspectos, tendo como
objetivo principal o acompanhamento de sua evolução.
Este tipo de monitoramento é importante para se ter um controle da dívida
técnica. Isso permite que não se deixe que ela aumente em pontos críticos onde a
prioridade de pagamento é alta. Isso pode evitar com que o projeto entre em uma
falência técnica.
Os índices também são muito importantes para o monitoramento ao longo do
prazo. Isso ocorre, pois com os índices de diferentes datas é possível verificar a
evolução da dívida técnica em pontos chaves. Logo por meio dos índices é possível de
se tomar algumas providências a fim de inibir ou até mesmo diminuir o crescimento
desta dívida técnica em específico.
21
Capítulo 3
Análise de Métodos e Ferramentas
Neste capítulo serão analisados métodos e ferramentas que permitem a
identificação, medida e monitoramento da dívida técnica.
3.1. Métodos de Identificação
Existem diversos métodos e ferramentas que permitem encontrar possíveis
pontos de dívida técnica, embora muitos deles não tenham sido criados para este fim.
Estas ferramentas podem ser agrupadas em cinco grupos que são: análise
estática automática, code smells, padrões de design e grime, violações de
modularidade e testes. Porém, algumas delas, podem estar presentes em dois grupos
ao mesmo tempo.
3.1.1. Análise (de código) Estática Automática
Este tipo de método de análise verifica problemas em nível de linha de código
[8]. O código analisado pode ser tanto o código-fonte quanto o código compilado [9].
Esta análise é feita com base em violações de boas práticas de programação ou
padrões de projeto para a definição de nomenclatura.
Com este método é possível encontrar pontos que podem causar falhas ou
podem degradar alguns aspectos da qualidade do software.
Alguns exemplos de subcaracterísticas onde a dívida técnica pode ser
encontrada com este método:
● Práticas ruins de programação;
● Corretude;
● Experimentação;
● Internacionalização;
● Vulnerabilidade a códigos maliciosos;
● Desempenho;
● Segurança;
● Corretude de Multi-Thread e
● Estilo.
22
Mesmo que as ferramentas encontrem diversos tipos destas violações é
importante analisar o contexto do software para que se possam escolher aquelas que
realmente importam. Isso pode ser feito com base no modelo de qualidade que foi
definido para encontrar a dívida técnica.
É importante destacar que a dívida técnica encontrada com este método em
poucos casos estão relacionadas a defeitos no código. Em geral, elas estão
relacionadas a violações de bons padrões que implicam diretamente no aumento da
dívida técnica relacionada a manutenção. Ou seja, as dívidas técnicas encontradas
com este método devem ter um grande grau de interesse de pagamento caso o
sistema tenha que receber manutenção ou quando ele necessitar de implementação de
novas funções.
3.1.2. Code Smells
O conceito de code smells foi definido por Matin Flower [12] e descreve
problemas relacionados com orientação a objetos e outros problemas comuns que
envolvem conjuntos de linhas de código.
Como code smells envolve uma variedade de problemas é necessário que
várias técnicas sejam adicionadas ao método para que se possa identificá-los, seja de
forma manual ou de forma automática.
Seguem alguns problemas que são definidos:
● Código Duplicado;
● Métodos/funções longos;
● Classes/Módulos longos;
● Métodos/funções com uma grande lista de parâmetros;
● Mudanças divergentes;
● Aglomeração de dados;
● Mudanças de afirmação.
Em geral, os problemas encontrados exigem uma refatoração para que possam
ser corrigidos. Logo, a dívida técnica encontrada com este tipo de problema no código
está fortemente ligada a manutenção e reuso. Além disso, muitos critérios utilizados
dizem respeito a confiabilidade, a segurança e a eficiência.
Neste nível, só é possível encontrar parte da dívida técnica de modo manual
com assistência do computador. Isso porque alguns itens são intuitivos e nem sempre
podem ser consideradas dívidas técnicas, já que são essenciais e não podem ser
alterados.
23
3.1.3. Padrões de Design e Grime
Os padrões de design têm como objetivo fazer com que o código-fonte seja mais
fácil de realizar manutenções e que seja menos propenso a defeitos e falhas [8]. Ele
faz isso por meio de descrições de como as classes podem trabalhar juntas.
O acumulo dos códigos que estão fora de conformidade com os padrões de
design formulados para determinados software são chamados de grimes [9]. Estas
inconformidades podem ser geradas na criação do código ou em uma alteração, neste
último caso, está quebra de integridade será chamada de rot.
Tanto grimes quanto rot são considerados dívidas técnicas, já que quebram
propriedades de qualidade definidas para o projeto.
Os padrões de design definem padrões de:
● Criação;
○ Abstrações;
○ Construtores;
○ Protótipos;
● Estrutural;
○ Adaptadores;
○ Compositores;
○ Proxy;
● Comportamental;
○ Comandos;
○ Interpretadores;
○ Iteradores;
● Concorrência;
○ Objetos ativos;
○ Verificação dupla;
○ Objeto monitor.
Os conceitos de padrões de design estão associados, em geral, a um nível mais
alto do software. Portanto, para identificar problemas nesses padrões, as vezes
necessita-se de análises complexas. Logo, é difícil encontrar ferramentas que
verifiquem problemas de padrões de design.
3.1.4. Violações de Modularidade
Em softwares grandes, módulos representam subsistemas que são geralmente
desenhados para evoluir de forma independente [9]. Estes módulos também podem ser
24
relacionados de maneira explicita a outros módulos. Quando estes módulos
relacionados não evoluem juntos, pode ocorrer uma discrepância.
As discrepâncias podem desviar a arquitetura do software e gerar violações de
modularidade.
As violações de modularidade geram dívida técnica, primeiramente, pois violam
uma regra. E também, pode ocorrer um efeito cascata atingindo vários módulos do
sistema. Por estar num nível alto de abstração é difícil identificar este tipo de violação
automaticamente, uma das maneiras é por meio de testes.
Um exemplo de violação de modularidade é se um módulo pai é alterado, seus
filhos, no mínimo, devem ser revisados e eventualmente alterados para preservar a
integridade e a interação.
3.1.5. Testes
O método de testes tem como objetivo encontrar falhas no software. Estas
falhas podem ser tanto erros, quanto violações de propriedades externas. Quando se
trabalha com softwares críticos é necessário se fazer teste por meio de verificação
formal, com a finalidade de garantir que o código-fonte corresponde ao modelo
elaborado. Já para softwares mais simples, o teste por meio de validação, em geral, já
é o suficiente [13].
Os testes são bons identificadores de dívida técnica, pois eles podem ser
escritos para identificar propriedades de qualidade. Logo, um teste pode ser capaz de
identificar se determinado trecho de código viola, ou não, uma dada propriedade.
Além disso, os testes são capazes de identificar problemas em abstrações em
um nível mais alto. Como por exemplo, se um determinado módulo está respeitando a
arquitetura do sistema.
Teste são capazes de identificar praticamente todas as propriedades de todas
as características do modelo de qualidade de produto. Porém, o custo de escrever os
testes pode ser um fator que inviabilize o processo.
A ausência de testes também pode indicar dívida técnica. Isso ocorre, pois os
códigos que não estão cobertos pelos testes podem apresentar problemas que
dificilmente serão encontrados por outro método de identificação.
25
3.2. Métodos de Medida
De uma forma geral, para realizar a medida da dívida técnica é preciso calcular,
para cada ponto, o custo de fazer com que a propriedade relacionada ao ponto seja
válida. Em seguida, basta somar todos estes custos, e isso pode ser chamada de
dívida técnica.
Após realizar a medida, é possível fazer agrupamentos destes pontos permitindo
a visão de interesses específicos, podendo estes serem em termos absolutos ou
relativos. Além disso, é possível construir escalas e gráficos para facilitarem a
visualização desta medida com relação ao projeto.
3.2.1. Calculando a Dívida Técnica
A dívida técnica [6] (DT) pode ser calculada pela seguinte fórmula:
sendo fi o custo de fazer a propriedade i ser válida em todos os pontos; calculada da
seguinte forma:
em que Pj é um vetor que descreve cada ponto que está sendo avaliado e,
representa o custo de fazer o ponto de avaliação (Pj) satisfazer a propriedade i.
26
3.2.2. Agrupando a Dívida Técnica
Muitas vezes é interessante saber qual é a dívida técnica para cada
características do sistema. Para isso, é possível agrupar a dívida técnica em
subcaracterísticas que são diretamente associadas a uma característica.
Em The SQALE Methods [6] é criado um índice para cada característica que
representa a soma da dívida técnica nas propriedades relacionadas a ela.
Estes índices foram criados para as seguintes características:
● Testabilidade (STI);
● Confiabilidade (SRI);
● Alterabilidade (SCI);
● Eficiencia (SEI);
● Segurança (SSI);
● Manuenção (SMI);
● Portabilidade (SPI) e
● Reuso (SRuI).
Como em um projeto podemos ter diversas partes interessadas, muitas vezes,
se faz necessário o agrupamento dos índices para que o valor possa refletir algo de
interesse.
Por exemplo, alguém poderia estar interessado se o sistema está funcionando
corretamente. Logo, ele poderia querer ver o agrupamento da dívida técnica de
testabilidade e confiabilidade juntos, gerando assim, um novo índice:
SCRI = STI + SRI
3.2.3. Dimensionando a Dívida Técnica
Para dimensionar a dívida em relação ao código-fonte, é possível criar índices
de densidade. Estes índices são definidos como a divisão dos índices absolutos pela
medida total possível para cada uma das propriedades associadas ao índice.
Por exemplo, o índice de testabilidade STI = 50. Então, é preciso encontrar o
total de horas que seria gasto se nenhum teste tivesse sido realizado, suponha que
este valor seja 500. Então temos índice de densidade de testabilidade STID = 50 / 500
= 0,1.
27
Esta técnica pode ser aplicada a qualquer índice absoluto, inclusive os que
agrupam mais de um índice. Sendo assim é possível criar um índice de densidade para
a medida da dívida técnica.
É importante observar que na prática, arquivos pequenos podem ter índices de
densidade altos. Por isso, ao calcular dentro de um projeto é preciso ponderar pelo
tamanho do arquivo ou calcular a densidade de um conjunto suficientemente grande.
3.2.2. Representações da Medida de Dívida Técnica
A medida da dívida técnica pode ser representada em diversas escalas ou utilizando
artifícios como gráficos e pirâmides.
3.2.2.1. A Escala do SQALE
Em SQALE são usadas três unidades de escala: classificação, porcentagem e
cor; que, em geral, são divididos em cinco ou mais valores. Esta escala é aplicada
diretamente nos índices de densidade e permitem verificar facilmente, o grau de dívida
técnica nos pontos de interesse.
Tabela de Escala [6]
Exemplo de uso: suponha que o índice de testabilidade (STI) seja igual a 18 e,
que todos os pontos possíveis somam 600. Logo o índice de densidade STID é igual a
0,03, que em porcentagem é igual a 3%. Logo sua classificação é C e sua cor é
amarela.
28
3.2.2.2. Kiviat
O gráfico de Kiviat é uma maneira de visualizar a dívida técnica de várias
características em apenas um lugar. Esse gráfico é dividido em setores que são dados
pela escala SQALE utilizada.
Para montar este gráfico, é preciso seguir os seguintes passos:
1. Para cada característica, marque o ponto em que se encontra a dívida técnica;
2. Ligue todos os pontos da dívida;
3. Para cada característica, marque o ponto com o valor máximo que se deseja ter
a dívida e
4. Ligue todos os pontos de valores máximos.
Gráfico de Kiviat para Dívida Técnica. [6]
29
3.2.2.3. Pirâmide SQALE
Como as caracterísitcas podem ser colocadas em ordem de importância, então
se pode construir uma pirâmide com as seguintes características:
● Cada campo, de cada linha recebe o valor da dívida técnica da
característica associada.
● Na última linha, toda a dívida da coluna deve ser somada.
Esta pirâmide permite visualizar a dívida acumulada de diferentes
características.
Pirâmide de Dívida Técnica [6].
30
3.3. Métodos de Monitoramento
Após identificar, medir e armazenar a dívida técnica é preciso utilizar alguns
métodos para monitorá-la. Estes métodos permitirão acompanhar a dívida
imediatamente ou a longo prazo. Os métodos mais precisos são os utilizados na dívida
técnica explícita, já a dívida técnica implícita utiliza os mais subjetivos.
O monitoramento da dívida técnica imediato permite verificar a situação atual, ou
de qualquer versão, do projeto. Além disso, o monitoramento pode ser feito analisando
as listas de várias versões do projeto, este é conhecido como monitoramento ao longo
do tempo. Estes métodos podem ser realizados analisando as listas de dívida técnica
ponto a ponto, por meio dos índices ou por qualquer outra forma de representação da
dívida técnica.
O que deve ser monitorado pode variar conforme a parte interessada. Por
exemplo: para o comprador do sistema pode interessar apenas a dívida técnica total do
projeto atual, já para responsável pelos testes do sistema pode interessar apenas a
dívida relacionada a teste e sua evolução ao longo do tempo.
É importante monitorar a dívida técnica [15], pois, ao contrário do que muitos
pensam, vários pontos da dívida técnica não possuem custo constante. Em geral, o
custo da dívida técnica aumenta ao longo do tempo, podendo levar o projeto a uma
falência técnica.
31
3.3.1. Métodos de Monitoramento da Dívida Técnica
Após a identificação e da medida da dívida técnica, é possível organizá-la em
listas que facilitaram o emprego de métodos para poder monitorá-la. Os métodos
podem tratar a dívida ponto a ponto, dando um enfoque mais detalhado, ou agrupando
os pontos, dando uma visão mais geral.
Mesmo após uma identificação detalhada dos pontos de dívida técnica, muitas
vezes, não será possível encontrar toda a dívida explicitamente. Isso ocorre, pois a
maioria dos projetos possui dívida técnicas implícitas, logo a identificação tornasse
impossível. Para tentar monitorar este tipo de dívida é preciso utilizar métodos que
procurem indícios de sua existência, principalmente os indicativos diários de dívida
técnica.
Alguns métodos para monitorar a dívida técnica são:
● Tracker: é realizado um acompanhamento específico para cada dívida técnica,
ou seja, para cada ponto é preciso verificar alguns itens como: a prioridade para
pagar, quando será pago, por quem será pago e informações adicionais. O
tracker ajuda a realizar um planejamento para o pagamento da dívida técnica,
bem como um histórico de seus pagamentos.
● Kanban: é uma ferramenta para fazer o acompanhamento das tarefas
realizadas em um projeto. Com a dívida técnica identificada é possível colocar
cada ponto, ou um grupo de pontos, como tarefa a ser realizada. Sendo assim o
monitoramento de quais dívidas foram, estão sendo ou serão pagas pode ser
feito de forma simples, utilizando o kanban.
32
● Monitorar a Felicidade do Cliente: um indício para saber se o projeto está indo
na direção certa, e consequentemente, sem um excesso de dívida técnica é
monitorar a felicidade do cliente. Quando um cliente começa a ficar impaciente,
irritado ou desinteressado pelo projeto, pode ser que seu projeto tenha excesso
de dívida técnica que afeta diretamente ele.
Imagem cedida por stockimages em http://www.freedigitalphotos.net
● Monitorar a Dificuldade de Modificar o Projeto: quando a equipe de
desenvolvimento começa a encontrar dificuldade para realizar modificações,
sejam elas corretivas ou implementação de novas funções, é um indício de que
a dívida técnica pode estar alta ou aumentando. Este monitoramento diz
respeito, principalmente, a dívida técnica das características de reuso,
manutenção e alterabilidade.
● Monitorar a Equipe: equipes que não estão felizes, trabalhando além do
horário, desorganizadas, com problemas técnicos ou qualquer outro problema
podem ter seus projetos prejudicados. Em especial, o código-fonte pode ser
afetado com dívida técnica devido a cansaço, desatenção, incapacidade técnica
ou outros fatores relacionados à equipe.
33
Imagem cedida por jscreationzs em http://www.freedigitalphotos.net
● Realizar Retrospectivas: realizar retrospectivas com os envolvidos no projeto é
importante para tentar identificar problemas e verificar se as expectativas de
todos foram correspondidas. Os problemas expostos nestes eventos devem ser
investigados a fim de verificar seu impacto na qualidade do produto, sendo estes
problemas, indícios de dívida técnica.
● Commits sobre o Tempo: um método para verificar se a equipe está
empenhada no projeto e verificar a complexidade de implementar novas funções
ou fornecer manutenção é acompanhar a quantidade de commits sobre o tempo.
Caso a curva fique decrescente pode ser um indício de que o projeto possui
dívida técnica.
34
https://github.com/SonarSource/sonar/graphs/commit-activity
35
3.4. Ferramentas
Nesta sessão serão apresentadas algumas ferramentas que podem auxiliar, ou
até mesmo realizar de forma automatizada, a identificação, medida e monitoramento da
dívida técnica.
Para cada ferramenta, será descrito para que ela serve, quais recursos ela
oferece, quais são os dados de entrada necessários, quais são as saídas produzidas e,
de um modo especial, como a ferramenta pode ser utilizada para ajudar no controle da
dívida técnica.
3.4.1. FindBugs
FindBugs é uma ferramenta livre, criada pela Universidade de Mayland, para
análise estática de código java. Esta ferramenta é compatível com GNU/Linux,
Windows e MacOS. Ela possui uma interface gráfica e fácil integração com o Ant e com
o Eclipse.
A análise estática não requer que o programa seja executado para que os
defeitos sejam encontrados. Em especial, o FindBugs analisa o bytecode e tenta
encontrar, por meio de uma lista de padrões, potenciais defeitos.
Como objetivo principal, o FindBugs é capaz de encontrar erros de corretude,
violações de boas práticas de desenvolvimento, erros de concorrência, problemas de
desempenho e vulnerabilidade a códigos maliciosos.
Por padrão, ele já vem como uma lista de padrões de defeitos, mas é possível
adicionar novos padrões de erros personalizados. Além disso, é possível retirar os
determinados padrões, ou seja, ele pode ser adaptado às necessidades de cada
projeto.
36
O FindBugs aceita como entrada arquivos de classes e .jar. Ele aceita, também,
diretórios ou arquivos .zip, neste caso ele faz uma varredura para encontrar os arquivos
de interesse.
É possível informar também os padrões de defeitos que serão utilizados na
análise, tanto os que já vêm com a ferramenta, quanto os personalizados.
A ferramenta permite decidir o tipo e grau da análise e dos relatórios e outras
opções que ajudam a identificar os defeitos.
Após processar o FindBugs retorna uma listagem de possíveis defeitos. Esta
listagem pode ser organizada por pacotes, classes, prioridades, categorias, tipos de
defeitos e tipos de padrões. A listagem pode ser vista na interface gráfica ou ser
exportada como xml, html, emacs, xdocs.
Para cada um dos defeitos, ele indica em qual padrão de defeito que se
enquadra e relaciona o defeito com o código-fonte. Isso facilita verificar se é realmente
um defeito e possivelmente corrigi-lo.
No contexto de dívida técnica, esta ferramenta pode ser utilizada para identificar
defeitos em potências. Estes defeitos podem ser erros, o que afeta diretamente a
qualidade do código, ou podem ser violações de padrões, que afetam o
desenvolvimento futuro e a manutenção.
Se utilizada junto ao processo de compilação, defeitos podem ser corrigidos
rapidamente, não gerando assim juros sobre a dívida.
3.4.2. Code Vizard
O Code Vizard [20] é uma ferramenta que varre repositórios e permite visualizar
históricos de código e métricas sobre o tempo.
Esta ferramenta prove ao usuário uma melhor visualização das mudanças e da
qualidade do software.
37
Code Vizard [20]
No contexto de dívida técnica, esta ferramenta pode ser utilizada para identificar
defeitos em especial com relação a code smells. Ela faz isso devido a sua visualização
do código e pela marcação das métricas que estão fora do padrão desejado.
3.4.3. Marple
A ferramenta Marple [21] (Metrics and Architecture Recognition PLug-in for
Eclipse) tem como objetivo reconhecer, em código Java, arquiteturas de software e
padrões de design.
O Marple identifica, de maneira estática, erros nos padrões de design por meio
de pistas, que são estruturas de código particulares, e detalhes que dariam indício da
presença da violação no código.
38
Arquitetura do Marple [22]
O Marple [22] é formado por quatro módulos que interagem entre si por
transferência de xml. Estes módulos são:
● Detector de Informações de Engenharia: recebe uma árvore de análise sintática
que representa o código-fonte. Este módulo coleta elementos básicos (pistas,
padrões de design elementares e micro padrões), que são usados para detectar
padrões de design e métricas que muitas vezes podem indicar a presença de
padrões de design no código.
● Joiner: baseado nas informações do Detector de Informações de Engenharia ele
extraí arquiteturas que podem ser comparadas as de padrões de design. As
classes podem ser vistas como nós de um grafo e os elementos básicos como
arestas conectando estes nós.
39
● Classificador: utilizando vários níveis de probabilidade, o módulo tenta inferir
quais das estruturas são realmente padrões de design. Com isso, ela diminui a
quantidade de falsos positivos, tentando se aproximar da teoria.
● Reconstrução da Arquitetura do Software: este módulo reconstrói a arquitetura
baseando-se principalmente nas informações passadas pelo Detector de
Informações de Engenharia, tanto elementos quanto métricas. Ele usa, também,
a árvore de análise sintática para fazer a reconstrução.
Como saída, a ferramenta produz uma visualização dos resultados de análise do
projeto. Ela retornará tanto o resultado produzido pela identificação de padrões de
design quanto da arquitetura do software.
Esta ferramenta pode ser usada, no contexto de dívida técnica, para analisar
violações na arquitetura e principalmente para encontrar defeitos ou a ausência de
padrões de design que deveriam estar incorporados ao software.
3.4.4. CodeRush
O CodeRush [23] é uma ferramenta para Microsoft Visual Studio que permite
visualizar intuitivamente o código, validar a rapidamente a qualidade e simplificar a
complexidade de sistemas de software.
Esta ferramenta permite analisar o código em busca de defeitos e soluções como:
● Sugestões de melhoria: ocorre quando o código é válido, mas pode ser
melhorado.
● Avisos: o código é válido, mas não está sendo usado.
● Erros: o código é inválido.
40
● Code Smells: o código é válido, mas entra nos padrões de defeitos conhecidos
como code smells.
O CodeRush possui um gerador de código que, a partir de pequenas
abreviações, expande uma quantidade definida de código. Esse gerador também é
capaz de trabalhar enquanto o programador está digitando e tenta completar o código
que está sendo digitado.
A ferramenta permite diferentes formas de visualização do código, facilitando o
entendimento. Ela permite personalizar a coloração do código definindo previamente,
ou automaticamente enquanto o debugging está sendo realizado. Ela cria, também,
uma árvore para cada expressão aritmética, permitindo verificar em quais nós estão
uma dada variável. Além, de colorir linhas, ela é capaz de colorir regiões de código tais
como métodos, definições e comentários.
O CodeRush ainda permite uma refatoração simplificada de código. Permitindo
que o código fique mais fácil de ler e diminua o custo de manutenção. A refatoração
permite reordenar os parâmetros de um método, alterar nomes, extrair métodos e fazer
refatoração em cascata.
Ela também possui um limpador e formatador de código. O formatador permite
padronizar as formatações de códigos para o projeto, gerando um aviso quando a
formatação não é respeitada, podem está ser formatado automaticamente. Já o
limpador, indica partes de códigos que não estão sendo usadas e códigos que não
podem ser atingidos.
Como esta é uma ferramenta totalmente integrada a IDE, os dados de entrada
são coletados diretamente e sua saída é integrada com o editor de códigos, menus e
janelas.
No contexto de dívida técnica esta ferramenta pode ajudar a identificar e eliminar
erros e code smells. Devido à integração com a IDE e a personalização, esta
ferramenta pode aumentar a produtividade, diminuindo o tempo de pagar a dívida e
detectando os defeitos rapidamente enquanto o código está sendo digitado.
3.4.5. ReSharper
O ReSharper [24] é uma ferramenta para Microsoft Visual Studio que faz
inspeção de código, refatoração automática, permite uma navegação rápida e é um
assistente de código.
41
Esta ferramenta prove análise continua de qualidade de código, aplicando mais
de 1.300 inspeções de código. Ela é integrada na IDE e permite visualizações
instantâneas de todos os erros e problemas.
Ela detecta erros e code smells e mostra avisos, sugestões e dicas. Ele
apresenta os problemas tais como:
● Declarações públicas sem uso;
● Métodos públicos que não estão sendo usados;
● Campos públicos sem uso;
● Eventos abstratos ou virtuais que não estão sendo chamados e
● Campos que poderiam ser privados, mas estão como públicos.
Além da visualização diretamente no código, o ReSharper possui uma área de
análise, onde todos os defeitos são exibidos em uma lista agrupada por arquivos.
A ferramenta também permite criar inspeções de códigos personalizadas. Isso
faz com que ela se adapte a qualquer projeto.
O ReSharper possui um gerador de códigos que funciona integrado com a IDE,
permitindo a complementação de código, geração de métodos e classes inexistentes. A
geração de códigos também pode ser feita por templates, que ao serem ativados
expandem e geram códigos pré-configurados.
Ele também possui um limpador de código. Essa característica combina
formatação com remoção de redundância de código e aplica as convenções de código
definidas pela a equipe.
Esta ferramenta pode encontrar erros e code smells, o que ajuda na
identificação da dívida técnica. Além disso, como ela é uma ferramenta totalmente
integrada na IDE e personalizável, ela ajuda na produtividade da equipe, baixando o
tempo de pagamento da dívida e também permite detectar os defeitos enquanto o
programador está codificando.
42
3.4.6. Gendarme
Gendarme [25] é uma ferramenta extensível baseada em regras para encontrar
problemas em aplicações e bibliotecas da família .NET. Como se trata do projeto Mono,
esta ferramenta é capaz de rodar tanto em ambiente Windows quanto em Linux.
A ferramenta inspeciona os programas e bibliotecas e procura por padrões de
defeitos no código, problemas estes, que em geral, os compiladores não tratam.
O Gendarme possui um runner que é o responsável por executar a análise,
carregar as regras, carregar os códigos em assembly e gerar um relatório com os
defeitos encontrados. Este runner pode ser executado a partir de linha de código ou um
sistema visual que permite fornecer as informações passo-a-passo.
As regras utilizadas por esta ferramenta estão divididas nas seguintes
categorias:
● Más práticas;
● Concorrência;
● Corretude;
● Design;
● Exceções;
● Interoperabilidade;
● Manutenção;
● Nomenclatura;
● Desempenho;
● Portabilidade;
● Segurança;
● Code Smells e
● Interface de Usuário.
43
http://pages.infinit.net/ctech/gendarme-wizard.jpeg
No contexto da dívida técnica, esta ferramenta pode ser utilizada para encontrar
defeitos em potencial, especialmente, code smells. Além disso, ela cobre diversos
pontos definidos pelos modelos de qualidade de produtos.
3.4.7. FxCop
O FxCop é uma ferramenta que analisa código em assembly em busca de
melhorias de design, localização, desempenho e segurança. Esta ferramenta foi
desenvolvida para assembly gerado por linguagens da família .NET.
Esta ferramenta utiliza mais de 200 padrões de defeitos que são classificados
nas seguintes categorias:
● Interoperabilidade;
● Design;
● Globalização;
● Nomenclatura;
● Desempenho;
● Segurança;
44
● Uso;
● Manutenção;
● Portabilidade e
● Confiança.
O FxCop pode ser utilizado tanto via linha de comando quanto interface gráfica,
permitindo gerenciar projetos, alvos, regras e as mensagens de retorno da análise.
Tela de mensagens do FxCop [26]
No contexto de dívida técnica o FxCop pode ser usado para identificar defeitos,
muitos deles relacionados pelo modelo de produto. Sendo assim, muitos destes
defeitos podem ser considerados como dívida técnica.
3.4.8. CLIO
CLIO [27] é uma ferramenta desenvolvida para encontrar defeitos de violações
de modularidade. Ele funciona comparando como os componentes deveriam se
relacionar e como, de fato, eles se relacionam.
A ferramenta identifica a violação de modularidade caso dois componentes, ditos
independentes, trabalhem em dependência para realizar qualquer operação.
O CLIO possui três componentes:
1. Calculador de acoplamento estrutural define como dois componentes podem
interagir.
45
2. Identificador de mudanças de acoplamento verifica como os componentes estão
realmente acoplados.
3. Gerador de resultado compara os resultados do calculador de acoplamento com
o de mudanças, verificando as divergências entre os dois modelos ele indica
onde ocorrem violações de modularidade.
Visão geral do Arcabouço CLIO [27].
Com os resultados obtidos por esta ferramenta é possível verificar facilmente
quais módulos são independentes e quais estão trabalhando em conjunto.
46
Tabela de independência do Maze Games [27].
No contexto de dívida, técnica esta é uma ferramenta muito útil, pois é uma das
poucas ferramentas encontradas que permite identificar defeitos de violações de
modularidade, sendo essências para manter o código como planejado e evitar gastos
desnecessários na manutenção.
3.4.9. Junit
O Junit [28] é um framework livre que permite aos programadores escreverem
testes automatizados para seus programas Java. As grandes IDE’s de
desenvolvimento Java já incluem o plugin para a execução e visualização do resultado
de testes.
Para que o Junit possa ser usado de maneira efetiva, algumas convenções e
anotações foram criadas:
● As classes de teste usualmente possuem o seguinte nome: [nome]Test.java.
Neste arquivo é preciso importar o junit;
● Existe o método de SetUp (anotado com @Before) para fazer configurações
antes de executar os testes;
47
● Cada método de teste deve ser anotado com @Test;
● Caso queira rodar mais métodos depois da realização dos testes, deve anotar os
métodos com @After e
● Os asserts (e outras variações) executam a checagem se o valor resultado é
igual ao valor esperado, se algum dos asserts falharem o método todo é
marcado como falho.
Para cada classe de teste do Junit retorna um “And” dos resultados dos asserts
(verdadeiro ou falso). Nas ferramentas como o Eclipse para cada classe de teste é
mostrado em quais métodos de teste foram verdadeiros ou falsos.
Esta ferramenta também mostra um resultado geral com quantos testes deram
positivo e quantos testes falharam.
Existem outras ferramentas como Mockito, DbUnit e o Selenium que ajudam a
construir testes mais poderosos, permitindo validar desde o simples funcionamento
isolado de uma classe, passando pela integração até chegar nos testes de aceitação.
No contexto de dívida técnica, o Junit, e as outras ferramentas de testes, podem
ser utilizados para validar os requisitos do software, tentando garantir que tudo que foi
planejado foi corretamente implementado e que o sistema está se comportando de
maneira satisfatória.
48
3.4.10. Eclemma
EclEmma [29] é uma ferramenta para o ambiente de desenvolvimento Eclipse
feita em Java, open-source e baseada no Emma que serve para execução de teste e
análise da porcentagem do código-fonte que está coberta pelos testes automatizados.
Esta ferramenta permite analisar a cobertura de vários tipos como: cobertura de
método, cobertura de decisão/branch, cobertura de linha de código e cobertura de
condição.
O Eclemma é uma ferramenta integrada a IDE Eclipse, podendo marcar de
diferentes cores o código-fonte para dar uma outra alternativa de visualização da
cobertura dos testes.
Além desta integração com a IDE, a ferramenta é capaz de exportar os
resultados para diversos formatos como: HTML, XML, CSV ou JaCoCo.
No contexto de dívida técnica, esta ferramenta pode ser usada para verificar se
os testes estão realmente cobrindo a parte desejada do código. Além disso, a cobertura
de código pode ser uma métrica utilizada para determinar se existe dívida técnica, já
que um sistema coberto de testes faz com que ao se alterar ou inserir novos códigos, o
código já existente não seja afetado, não gerando novos erros.
49
3.4.1. Sonar Qube
O Sonar Qube [30] é uma plataforma livre para gerenciar qualidade de código.
Ela possui uma grande quantidade de recursos em seu núcleo, tais como: métricas
padrões, regras de código, unidades de teste e, além disso, possui mais de 50 plugins
disponíveis.
Esta plataforma está preparada para os sete eixos da qualidade de código:
Arquitetura e design, duplicações, testes de unidade, complexidade, possíveis
erros, regras de código e comentários.
7 eixos de qualidade do Sonar [30]
O Sonar tem um caminho muito eficiente de navegação, um balanço entre
visualização de alto-nível, painel de ferramentas, máquina do tempo e ferramentas para
encontrar defeitos. Isso permite descobrir rapidamente projetos e/ou componentes que
estão em dívida técnica para os planos de ações estabelecidos.
Estrutura alto-nível do Sonar [30]
50
Mais de 20 linguagens de programação e de marcação são cobertas através dos
plugins, entre elas estão Java, C/C++, C#, PL-SQL, .NET, PHP e XML, porém algumas
extensões são oferecidas comercialmente. Também o gerenciamento de portfólios de
projetos pode ser feito utilizando serviços profissionais.
Além dos plungins, o Sonar permite integração com Servidores de Integração
Continua tais como o Jenkins, Hudson, Atlassian Bamboo e Apache Continuum. A
plataforma também permite integração com o Eclipse, facilitando e aumentando a
produtividade de seu uso.
É possível usar o Sonar em diferentes Sistemas Operacionais que são:
● Linux Power PC na versão 64 bits.
● Linux X86 nas versões 32 e 64 bits.
● Mac OSX Universal nas versões 32 e 64 bits.
● Solaris Sparc nas versões 32 e 64 bits.
● Solaris X86 na versão 32 bits.
● Windows X86 nas versões 32 e 64 bits.
Arquitetura do Sonar Qube
O Sonar é composto por três componentes:
1. Um banco de dados que armazena as configurações e os resultados das
análises de qualidade.
2. Um servidor web que é usado para fazer as configurações e navegar pelos
resultados das análises.
3. Um cliente que rodará o analisador de código fonte para processar os dados
do projeto.
3.1. Um visualizador que visualizará os resultados das análises fora da
interface do servidor web.
51
Arquitetura do Sonar Qube [30]
Banco de Dados
O Sonar possui suporte a uma série de banco de dados. Se o objetivo é
simplesmente rodar rápidos testes ou fazer uma demonstração pode ser usado o H2 ou
Apache Derby que são bancos de dados que está incluso no pacote do Sonar e não
requer instalação.
Entretanto H2 e Apache Derby não devem ser utilizados em ambiente de
produção devido a sua capacidade e eficiência limitadas. Para tanto, banco de dados
mais robustos tais como: Microsoft SQL Server, Mysql, Oracle ou PostGress.
Servidor Web
A tarefa de configuração e verificação de resultados do Sonar é fornecida pelo
Servidor Web. Atualmente, o Sonar utiliza como aplicação de servidor web o Jetty 6,
que já está incluso no pacote do Sonar.
Porém é possível configurá-lo para utilizar Apache Tomcat, nas versões: 5.5, 6.0
e 7.0. Esta opção pode gerar melhor desempenho no sistema, e facilitar
administradores de rede e desenvolvedores a incluírem o Sonar em seus servidores.
A interface web oferece suporte e testes aos navegadores mais utilizados que
são:
52
● Microsoft Internet Explores nas versões: IE7, IE8, IE9;
● Mozilla Firefox;
● Google Chrome e
● Safari.
Cliente
O cliente é responsável por rodar o analisador de código e enviar o código ao
servidor que o armazenará no banco de dados.
O cliente poderá fazer consultas de todos os seus projetos, podendo facilitar o
uso. Um exemplo de cliente é o plugin do Eclipse.
Escopo de Análises
O Sonar tem capacidade para realizar análises em mais de 20 linguagens de
programação. O resultado desta análise será essencialmente medidas de métricas e
violações de regras de codificação. No entanto, o que é analisado pelo Sonar irá variar
dependendo da linguagem em questão:
○ Em todas as linguagens o Sonar realiza uma análise estática do código
fonte.
○ O Sonar pode realizar análises estáticas de códigos compilados em
algumas linguagens como Java e C#.
○ O Sonar pode realizar análises dinâmicas de código em algumas
linguagens como Java e C#.
Para realizar as análises existem vários clientes do Sonar Server, dentre eles
estão: Sonar Runner, Sonar Ant Task, Maven, Gradle e CI Engines. Neste texto
falaremos apenas do Sonar Runer, que é o cliente recomendado.
Sonar Qube e Dívida Técnica
Nas versões anteriores a 4.0 o sonar possuía um plugin com um medidor de
dívida técnica, este mostrava um gráfico de pizza da distribuição da dívida técnica nas
características e informações gerais, como por exemplo, a quantidade de código que
estava em dívida técnica, o valor e a quantidade de dias necessários para pagar a
dívida.
53
Plugin para o Sonar
Nas versões mais recentes, o Sonar Qube já vem com um medidor que indica a
quantidade de dias necessários para pagar a dívida técnica, porém esta é a única
informação explicita fornecida.
As demais informações podem ser inferidas a partir da análise das métricas de
código-fonte e a partir da lista de defeitos do código.
3.4.12. Sonar Qube – Plugin Techinical Debt Evalutaion (SQALE)
Esta é uma extensão comercial do Sonar Qube, que implementa a metodologia
SQALE e integrada a plataforma é capaz de realizar a identificação, medida e
monitoramento da dívida técnica.
Ela utiliza como entrada os dados já armazenados pelo Sonar Qube. Ela busca
no banco de dados métricas e informações que, em geral, podem ser indícios de dívida
técnica. Ela faz uma análise e para cada um destes pontos, marca o tipo de violação
definindo assim o risco e a característica a qual ela pertence.
Após identificar, todos os pontos de dívida técnica, para cada um deles é feito
uma aplicação em uma função de custo, previamente definida, que retorna a
quantidade de dias necessários para realizar o pagamento daquela dívida e armazena
está informação.
Com estas informações de medida, ele é capaz de realizar um monitoramento
da dívida técnica, mostrando as informações nos seguintes formatos:
54
Visão Geral
Esforço Realizado para o Pagamento da Dívida Técnica
Distribuição da Dívida Técnica nos Arquivos
Distribuição do Risco da Dívida Técnica
55
Distribuição da Dívida nas Características
Distribuição da Dívida nas Características ao Longo do Tempo
Distribuição da Dívida Técnica nas Características e Subcaracterística
56
57
Capítulo 4
Resultado da Aplicação em Projetos de Software Livre
Para saber como a teoria se comporta no mundo real, será realizada a aplicação
do método SQALE em diversos projetos de software livre a fim de identificar e medir a
quantidade de dívida técnica em cada um deles.
4.1. Análise Preliminar
Para realizar os testes e análises foi utilizado o servidor de demonstrações da
plataforma Sonar Qube (http://nemo.sonarqube.org), chamado de servidor Nemo. Este
servidor possui a análise de mais de 200 projetos de software livre, dentre eles os
próprios softwares que compõem a plataforma do Sonar Qube, diversos projetos da
Apache Foundation (Maven, Tomcat, Jena e muitos outros) e outros projetos
(Eclemma, Jacoco e Struts).
Além disso, o servidor possui instalado o plugin “Technical Debt Evalutation
(SQALE)” (http://www.sonarsource.com/products/plugins/governance/sqale/). Este
plugin implementa a metodologia SQALE para realizar a identificação, medida e
monitoramento da dívida técnica.
O servidor Nemo foi escolhido pelo fato de já ter a análise da dívida técnica de
muitos projetos de software livre. Outro fator importante foi que ele já possui a
instalação do plugin de dívida técnica. Primeiro, porque o plugin é completo para fazer
as análises desejadas. Segundo, porque este é plugin pago e só seria possível ter a
acesso a versão de testes. E por fim, porque ele é uma implementação da metodologia
SQALE, a qual este texto a referencia diversas vezes.
Para escolher quais projetos seriam analisadas, foi feito uma análise preliminar
de mais de oitenta projetos, uns escolhidos ao acaso, outros escolhidos pela sua
importância e outros por utilizarem uma linguagem diferente de Java.
Esta análise preliminar envolveu criar cinco grupos utilizando o critério da
classificação SQALE (que varia de A, a maior, até E, a menor). Infelizmente, não foi
encontrado nenhum software com classificação E, portanto restaram quatro grupos.
58
Para cada grupo foi verificado se o projeto possuía algum diferencial em relação
a dias necessários para pagar a dívida técnica, quantidades de linhas de código, a
evolução da dívida ao longo do tempo, a distribuição da dívida nas características e a
distribuição do risco da dívida técnica.
Após esta análise, os projetos foram agrupados por semelhança e escolhidos
alguns representantes, por importância do projeto, para cada um destes agrupamentos.
Para o grupo A foi escolhido o Eclemma, o JDK 7 e o PHP CodeSniffer. Para o
grupo B foi escolhido o Source Forge. Para o grupo C foi escolhido o Paul Grifts’ C
Programming Examples. Para o grupo D o Google Code.
59
4.2. Aplicação em Projetos de Software Livre
Para relatar os resultados, será utilizada uma abordagem visual e condensada,
unificando os resultados para cada projeto, podendo assim, realizar uma análise geral
da dívida técnica em cada projeto.
4.2.1. Eclemma
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/364011?did=19
O projeto Eclemma possui uma dívida técnica absoluta e relativa baixa, sendo
necessário pouco mais de um mês contínuo de trabalho para pagá-la. A classificação
SQALE é A, ou seja, possui menos de 1% de dívida técnica.
A equipe de desenvolvimento costuma pagar a dívida técnica, porém nos últimos
meses este pagamento foi para zero, isso deve ter ocorrido devido ao fato de a dívida
técnica estar estabilizada.
É interessante observar que em um projeto controlado como este a dívida
técnica distribuída nos arquivos tem a grande maioria classificação SQALE A, tendo no
60
mínimo C. Isso significa que em qualquer arquivo de código do projeto a dívida técnica
não passa de 8%.
A maior parte do risco está nas funções de médio custo, representando mais de
80%. O custo de remediação de risco alto, baixo e muito baixo são praticamente
desprezíveis.
Com a pirâmide de distribuição da dívida técnica é possível observar que a
dívida está concentrada na característica de alterabilidade. É possível notar que a
característica de confiabilidade está praticamente toda em dívida técnica, mesmo que
isto represente menos de 20% da dívida.
61
Com este gráfico é possível ver que ao longo do projeto sempre a dívida técnica
se concentrou na alterabilidade, seguida da manutenção. Porém, é possível ver que
nas últimas versões, a confiabilidade sofreu um grande aumento relativo.
Este gráfico confirma que mais da metade do problema da dívida técnica está
relacionada com alterabilidade, ganhando destaque também a manutenção e
confiabilidade.
62
4.2.2. JDK 7
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/371518?did=19&period=0
O projeto JDK (Java Development Kit) possui uma dívida técnica absoluta alta,
sendo necessários mais de 6.400 dias para pagá-la, ou seja, se o projeto tivesse
apenas um desenvolvedor ela demoraria mais de nove anos para pagá-la.
Por outro lado, relativamente a divida é baixa, recebendo uma classificação
SQALE A, ou seja, possui menos de 1% de dívida técnica. Este contraste ocorre devido
a grande quantidade de linhas de código do projeto, ultrapassando um milhão de
linhas. Sendo assim, a dívida pode ser diluída no projeto.
Mais da metade dos arquivos possuem classificação SQALE A, porém existem
arquivos com classificações menores, tendo uma porcentagem considerável de B e C,
chegando até a E, que é a menor classificação possível.
Este projeto possui funções de custo com risco alto e muito alto, mas a grande
maioria da dívida está no risco médio. O risco muito baixo, também possui um valor
considerável se comparado com o total.
63
Com este gráfico é possível ver que no início do projeto a dívida se distribuía
entre todas as características, tendo algumas mais destaque que outras. Em certo
ponto a portabilidade, a segurança e a testabilidade, passaram a ser praticamente
desprezíveis. Na última versão, porém, a portabilidade voltou a aumentar
significativamente.
Com este gráfico vemos que está versão do sistema, possui uma distribuição
equilibrada das características da dívida técnica, sendo apenas a segurança e a
testabilidade ocupando pequenas fatias.
64
4.2.3. PHP CodeSniffer
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/417057?did=19
Este é um projeto na linguagem de programação PHP que possui uma dívida
técnica absoluta e relativa baixa, sendo necessário pouco menos de 20 dias para pagá-
la. A classificação SQALE é A, ou seja, possui menos de 1% de dívida.
Com este gráfico é possível ver que nas últimas versões, não tem sido feito
esforços para pagar a dívida. Isso pode estar ocorrendo, pois a quantidade de dívida é
baixa, e muitas vezes não é interessante dispender esforços para pagá-la.
Este gráfico de distribuição mostra que todos os arquivos do projeto possuem
classificação SQALE A, sendo este mais um motivo pelo qual esforços não estão
sendo feitos para pagar a dívida.
65
A maior parte da dívida técnica está concentrada na testabilidade, o que já era
de esperar, pois o PHP é uma linguagem que não tem tantos artifícios quanto Java
para a realização automatizada da execução de testes. Além disso, o Sonar pode não
estar preparado para verificar os testes e sua cobertura. Outro item que se destaca é a
manutenção.
Este gráfico mostra que esta versão do sistema possui realmente muita dívida
com relação à testabilidade, seguido de manutenção e com um pouco de dívida na
alterabilidade.
66
4.2.4. Sonar Qube
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/48569?did=19
Este projeto é a plataforma Sonar Qube utilizada para realizar as análises. Ele
possui uma dívida técnica absoluta alta, sendo necessário pouco mais de meio ano
para pagá-la.
Por outro lado, relativamente a divida é baixa, recebendo uma classificação
SQALE A, ou seja, possui menos de 1% da dívida. Este contraste ocorre devido a
grande quantidade de linhas de código do projeto, ultrapassando oitenta mil linhas.
Sendo assim, a dívida pode ser diluída no projeto.
A maior parte dos arquivos possui classificação SQALE A, porém existem
arquivos com classificações menores, chegando até a D e E, que são as menores
classificações possíveis.
67
Este projeto possui funções de custo com risco alto muito pequeno, sendo que a
grande maioria da dívida está no risco médio. O risco muito baixo, também possui um
valor considerável, chegando a quase 30% do risco.
Com este gráfico é possível ver que durante o projeto a distribuição da dívida
técnica não se alterou muito. Sendo apenas as características de reuso, eficiência e
testabilidade as únicas que são praticamente desprezíveis com relação às demais. A
alterabilidade por outro lado, possui um destaque sendo a que possui a maior
quantidade.
68
Com esta pirâmide é possível visualizar facilmente a distribuição atual do
projeto, comprovando a desprezabilidade do reuso, eficiência e testabilidade e o
destaque da alterabilidade.
69
4.2.5. Source Forge
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/176178?did=19
Em termo absoluto o projeto Source Forge possui uma dívida técnica alta, sendo
necessário mais de 1.600 dias para pagá-la, ou seja, seria necessário meio ano para
que uma equipe com dez desenvolvedores pudessem realizar todo pagamento.
Já relativo à quantidade de linhas de código a quantidade de dívida técnica está
controlada, recebendo uma classificação B da medida SQALE, o índice de densidade
está entre 1% e 2%. Para levar a dívida para um nível A que, em geral, é o desejado, é
preciso de 493,1 dias para pagá-la.
No último ano a equipe de desenvolvimento deste projeto, trabalhou para
significativamente diminuir a dívida técnica, ficando três meses sem pagamento e
retornando novamente ao pagamento.
70
A maior parte da dívida está concentrada no risco médio, representando mais de
80%. Além disso, a dívida de risco muito baixo possui uma quantidade absoluta de
custo alto, porém, algumas vezes não é interessante a equipe pagar ou colocar como
prioridade o pagamento deste tipo de dívida.
Com esta pirâmide é possível ver que a dívida técnica está concentrada nas
características de manutenção, alterabilidade e confiabilidade. A testabilidade também
possui uma expressividade comparada com as demais. É interessante observar que
não existe dívida técnica com relação ao reuso, sendo que já foram trabalhados cerca
de 1.600 horas nessa característica.
71
Este gráfico mostra que a evolução da dívida técnica diminuiu nas últimas
versões e que ela sempre se concentrou em manutenção, alterabilidade e
confiabilidade, seguida de testabilidade.
72
4.2.6. Paul Grifts’ C Programming Examples
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/359742?did=19
Este projeto é desenvolvido na linguagem C. A dívida técnica absoluta não é
muito alta, sendo necessários 52,4 dias para pagá-la. Porém, a relativa é alta, um dos
motivos é que a quantidade de linhas de código é de um pouco mais de mil linhas.
Sendo assim, a dívida não consegue ser muito bem diluída pelo código.
Com este gráfico é possível ver que menos da metade dos arquivos do projeto
possuem classificação SQALE A, sendo que estes são quase as mesmas quantidades
de classificação C e D, possuindo ainda uma quantidade expressiva de E.
A grande maioria da dívida técnica está nas funções de custo com risco médio,
sendo esta quase 95%. O restante do risco está, principalmente, no nível baixo, porém
esta quantidade é quase 20 vezes menor que a principal.
73
A quantidade baixa de dívida técnica do início do projeto pode ser explicada,
pois o Sonar é preparado principalmente para a linguagem Java, podendo a plataforma
ter evoluído durante o projeto, sendo capaz de identificar melhor a dívida técnica na
linguagem C.
Na última versão é possível observar que a grande maioria da dívida está na
característica de portabilidade. Além disso, manutenção e a confiabilidade também
concentram uma quantidade significativa de dívida.
74
4.2.7. Google Code
Dados completos e interativos em:
http://nemo.sonarqube.org/dashboard/index/176188?did=19
Este projeto possui uma dívida técnica absoluta e relativa alta. Ele necessita
mais 900 dias para pagá-la e possui uma classificação SQALE D, ou seja, o projeto de
4% a 8% do projeto estão em dívida técnica.
Para melhorar os índices de dívida técnica e melhorar a classificação SQALE do
projeto seriam necessárias, 163,9 dias para a nota C, 625,5 para a nota B e 779,4 para
a nota A.
Apesar da classificação SQALE ser baixa num geral, a maior parte dos arquivos
possui classificação A, sendo que a classificação B e C, também, estão fortemente
presentes.
75
A maior parte da dívida técnica está concentrada nas funções de custo com
risco médio, passando de 90%. Junto com o fato dela também possuir as de risco alto
e muito alta é que justifica a classificação SQALE D.
A distribuição da dívida se manteve praticamente constante ao longo do projeto.
76
Com este gráfico é possível ver que a alterabilidade é a que possui a maior
quantidade de dívida técnica, seguidas da manutenção e confiabilidade. Já a
testabilidade e a portabilidade ocupam uma posição pouco expressiva comparada com
as demais. E a eficiência e segurança possível são praticamente desprezíveis.
4.3. Resultados das Aplicações
Para realizar as análises das aplicações foram utilizados os conceitos e
tecnologias descritos no capítulo 2 e os métodos e ferramentas apresentados no
capítulo 4.
Em especial, na parte conceitual foi utilizada a metodologia SQALE, esta
escolha foi feita devido ao fato dela permitir a identificação, medida e monitoramento da
dívida técnica. Por outro lado, o plugin utilizado é uma implementação desta
metodologia, com alguns artefatos a mais, que facilitam, principalmente, o
monitoramento.
Quanto às ferramentas, a base foi o Sonar Qube, por ser uma plataforma ela
permite a integração com diversas outras ferramentas e extensões. Internamente o
Sonar Qube utiliza o FindBugs, para encontrar defeitos, o Junit, para executar os testes
77
automatizados, e o Eclemma, para verificar a cobertura de testes. Os valores
produzidos pelas ferramentas são armazenados em banco de dados o que permite
uma análise e visualização posterior tanto pela plataforma quanto pelas extensões.
O plugin “Techical Debt Evaluation (SQALE)” integrado a plataforma permite, a
partir dos dados já produzidos, identificar a dívida técnica e agrupá-las conforme o tipo,
o risco e a característica. Após a identificação, para cada ponto encontrado são
aplicados funções de custo, previamente definidas, conforme o agrupamento a que o
ponto pertence, retornando um valor em dias de trabalho.
Logo, a soma da aplicação das funções em todos os pontos é a dívida técnica
absoluta representada em horas de trabalho. Além disso, estes custos são utilizados,
junto com o risco, para classificar o nível de dívida conforme a metodologia SQALE.
Com os dados produzidos, o plugin é capaz de gerar relatórios, que permitem o
monitoramento da dívida técnica. A análise pode ser feita em alto nível, como a
quantidade em dias de trabalho e a classificação SQALE, ou algo mais detalhado,
como verificar o código que possui a dívida técnica.
A análise realizada levou em consideração, principalmente, as medidas resumo,
tais como a classificação SQALE, dívida técnica em dias de trabalho, quantidade de
linhas de código, gráfico de esforço realizado para pagar a dívida técnica pelo tempo,
distribuição do risco da dívida técnica, histórico da dívida dividida pela característica,
pirâmide com a dívida e pagamento divida pela características e gráfico de pizza
multicamadas com a distribuição da dívida pelas características e subcaracterísticas.
Das análises podemos observar que o Eclemma é um dos projetos que melhor
se comporta, conseguindo manter o nível de dívida técnica absoluta e relativa baixa, já
projetos maiores, em relação à quantidade de linhas de código, como o JDK 7 é
possível observar que a dívida técnica absoluta costuma ser alta, mesmo que a relativa
consiga ser controlada e baixa.
Com isso, é possível afirmar que, na maioria dos casos, a quantidade de dívida
técnica é proporcional à quantidade de linhas de código de cada projeto, ou seja,
quanto maior o projeto, maior a dívida técnica absoluta ou vice-versa.
Outro fato, é que quanto maior a dívida técnica absoluta, maior é o tempo que os
grupos utilizam entre as versões para pagá-la, isso ocorre, pois muitas destas dívidas
são fáceis de pagar, logo é possível fazer o seu pagamento sem maiores
complicações. Já em projetos com a dívida técnica absoluta baixa, o tempo gasto é
78
menor, chegando muitas vezes a ser zero, pois a complexidade de pagar a dívida ou
até mesmo de encontrá-la é maior.
Os projetos com classificação SQALE A, mantem o nível de dívida técnica baixa
na característica de testabilidade, isso ocorre, pois mais e mais as equipes de
desenvolvimento se preocupam em validar o código produzido. Existe uma exceção em
relação às linguagens que não são Java, que mostram dívida técnica na testabilidade,
devido ao fato de não terem ferramentas integradas para poder validá-las.
4.4. Resultados Finais
Das análises realizadas, tanto a preliminar quanto a mais detalhada, pode-se
notar que os projetos de software livre com uma comunidade grande ativa, costumam
ter menos dívida técnica relativa do que projetos que não são tão populares. Isso pode
ocorrer, pois nesses projetos, diariamente, diversas pessoas trabalham a fim de prover
a melhoria de qualidade do código, o que impacta diretamente na dívida técnica.
É possível notar também, que os projetos que possuem dívida técnica absoluta
alta e não se propõem a pagá-la entre as versões, costumam ter a dívida técnica
relativa também alta. Isso ocorre, pois além de não pagar a dívida, mais dívida é
inserida a cada versão e, em geral, a complexidade do software aumenta, impactando
no custo de pagamento.
De um modo geral, é possível perceber que os projetos não cuidam
especificamente da dívida técnica, com algumas exceções, mas em projetos de grande
atividade, existe um cuidado com a qualidade do código-fonte o que evita diversos
defeitos que são considerados dívida técnica.
79
Capítulo 5
Conclusão
A dívida técnica está ganhando destaque no cenário de pesquisas acadêmicas e
na indústria. Isso ocorre devido ao fato de que, cada vez mais, os grupos de
desenvolvimento de software procuram melhorar a qualidade e manter o projeto ativo.
Nestes pontos, ter o controle da dívida técnica é muito importante, pois a partir dela é
possível saber, de uma forma geral ou detalhada, como está a qualidade do software.
Além disso, é possível definir se a manutenção ou implementações futuras podem ser
realizadas com custos que cabem ao projeto.
Já existem definições maduras para a dívida técnica como a realizada pela
Carolyn Seaman [1], que a define como uma metáfora para artefatos imaturos,
incompletos ou inadequados no ciclo de vida de desenvolvimento de software.
Ainda para definir a dívida técnica, pode-se utilizar os conceitos utilizados pela
metodologia SQALE [1], que a define a partir da ISO/IEC 25010:2011 [2]. Neste texto a
dívida técnica é definida como o custo de levar a qualidade do nível atual para o nível
desejado. Este custo pode ser expresso em dias de trabalho, custo monetário ou
qualquer outra representação simbólica.
Com relação à aplicação em projetos de software livre podemos concluir que a
quantidade de dívida técnica absoluta é diretamente proporcional à quantidade de
linhas de código.
Além disso, é possível observar que projetos que possui uma grande
comunidade ativa possui uma dívida técnica relativa baixa. Regularmente, estes
projetos realizam o pagamento da dívida, isso, muitas vezes, não ocorre
conscientemente, mas devido ao fato que cada vez mais as equipes de
desenvolvimento estão preocupadas com a qualidade. E melhorar a qualidade impacta
diretamente no pagamento da dívida técnica.
Na parte de aplicação, existem diversas ferramentas que podem ser utilizadas
para identificar a dívida técnica, porém, em geral, elas não foram criadas
especificamente para este fim.
80
Por outro lado, existe o Sonar Qube, que é uma plataforma para gerenciar a
qualidade de projetos de software, que permite, a partir de outras ferramentas, calcular
o total de dívida técnica de um projeto.
Porém sozinha esta ferramenta é muito limitada. Para se ter mais detalhes e
poder monitorar de um modo mais amplo e efetivo a dívida técnica é possível instalar o
plugin “Technical Debt”, porém este é pago.
5.1. Perspectivas Futuras
Na parte conceitual é necessário que várias pesquisas sejam realizadas, para
melhorar a teoria que envolve a dívida técnica, tornando-a mais precisa e pontual. Além
disso, é preciso desenvolver ou melhorar as metodologias para que a aplicação possa
ser feito de um modo mais fácil e padronizado.
Na parte de aplicação, é necessário utilizar as ferramentas já existentes para
criar uma plataforma que seja capaz de identificar diversos tipos de dívida técnica.
Desde as ligadas ao código-fonte até as de requisitos de usuário.
Na verdade, já existe essa plataforma, que é o Sonar Qube, porém vários tipos
de dívida técnica não são identificados, logo ela poderia ser usada para reunir as
ferramentas para realizar a identificação.
Quanto à parte de medida e monitoramento seria interessante criar um plugin
livre para que todos pudessem ter acesso tanto ao controle da dívida técnica, quanto a
uma maneira de estudar formas de implementação da metodologia.
81
Capítulo 6
Referências Bibliográficas
[1] Measuring and Monitoring Technical Debt, Carolyn Seaman and Yuepu Guo,
Advances in Computers, Vol. 82, 25-46, 2011.
[2] Technical Debt, Martin Fowler, 26 de fevereiro de 2009,
http://martinfowler.com/bliki/TechnicalDebt.html
[3] Managing Technical Debt, Steve McConnell, 10x Software Development, 1 de
Novembro de 2007.
[4] Evaluate your technical debit with Sonar, Olivier Gaudin, 11 de Junho de
2009,
http://www.sonarsource.org/evaluate-your-technical-debt-with-sonar
[5] Vídeo de Ward Cunnigham sobre dívida técnica, transcrito por June Kim e
Lawrence Wang, postado em 22 de Janeiro de 2011,
http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
[6] The SQALE Method - Definition Document, Jean-Louis Letouzey, Version 1.0,
27 de Janeiro de 2012.
[7] ISO/IEC 25010:2011 - System and software engineering - System and
software Quality Requirements and Evaluation (SQuaRE) - System and software
quality models, BSI Standards Publication.
[8] Identifying and Managing Technical Debt, Dr Nico Zazworca e Dra. Carolyn
Seaman (http://www.slideshare.net/zazworka/identifying-and-managing-technical-debt).
[9] Comparing Four Approaches for Technical Debt Identification, Nico
Zazworka, Antonio Vetro, Clemente Izurieta, Sunny Wong, Yuanfang Cai, Carolyn
Seaman e Forrest Shull.
[10] Measuring and Monitoring Technical Debit, Yuepu Guo, IDoESE 2009.
[11] Dívida Técnica: precisando de crédito? Ou “Como evitar que o cobrador
bata na sua porta, Alexandre Freire, Apresentação em 20/03/2013.
82
[12] Refactoring: Improving the Design of Existing Code, Mating Flower, Kent
Beck, John Brant, William Opdyke e don Roberts, 1ª edição Addison-Wesley
Professional, 1999.
[13] Introdução ao Teste de Software, Márcio Eduardo Delamaro, José Carlos
Maldonado, Mario Jino, Editora Campus, 2007.
[14] Take Action to Manage Technical Debt, G. Ann Campbell, 24 de Outubro de
2013
[15] Managing Software Debt - Build for Inevitable Change, Chris Sterling.
[16] FindBugs - http://findbugs.sourceforge.net/
[17] Análise Estática de Código com FindBubs, André Thiago -
http://andrethiago.wordpress.com/2010/05/20/analise-estatica-de-codigo-com-findbugs/
[18] FindBugs, Part 1: Improve the quality of your code, Chris Gridstaff, IBM -
http://www.ibm.com/developerworks/library/j-findbug1/
[19] FindBugs, Part 2: Writing custom detectors, Chris Gridstaff, IBM -
http://www.ibm.com/developerworks/java/library/j-findbug2/
[20] Tool Development, Nico Zazworka, http://www.nicozazworka.com/tool-
development/
[21] Essere (Evoluzione dei Sistemi Software e Reverse Engineering),
http://essere.disco.unimib.it/reverse/Marple.html
[22] Marple - Metrics and Architecture Recognition Plug-in forclipse, Francesca
Arcelli, Stefano Maggioni, Christian Tosi, Marco Zanoni,
http://essere.disco.unimib.it/reverse/files/MARPLE.pdf
[23] CodeRush, DevExpress, https://www.devexpress.com/Products/CodeRush/
[24] R# ReSharper, JetBrains, http://www.jetbrains.com/resharper/
[25] Gendarme, Mono-Project, http://www.mono-project.com/Gendarme
[26] FxCop, Microsoft Developer Network, http://msdn.microsoft.com/en-
us/library/bb429476(v=vs.80).aspx
83
[27] Detecting Software Modularity Violations, Sunny Wong, Yuanfang Cai,
Miryung Kim e Michael Dalton.
[28] Junit, http://junit.org/
[29] Eclemma, http://www.eclemma.org
[30] Sonar Qube, http://www.sonarqube.org
[31] Technical Debt Plugin,
http://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin
[32] Evaluate your Technical Debt with Sonar, http://www.sonarqube.org/evaluate-
your-technical-debt-with-sonar/
[33] Techinical Debt Evalutaion (SQALE),
http://www.sonarsource.com/products/plugins/governance/sqale/
84
Parte II Subjetiva
85
Capítulo 7
Análise Subjetiva
A computação sempre esteve muito presente em minha vida. Aos seis anos de
idade ganhei meu primeiro computador (um Intel i386) e comecei a dar meus primeiros
passos. Aos dez anos de idade, já fazia cursos de computação desde o básico de
sistemas operacionais, a pacote Office a até manutenção de computadores.
Como tinha bastante interesse por computadores, aos catorze anos iniciei um
colegial técnico em informática. Aos quinze, paralelamente, iniciei outro curso técnico
em informática, este com mil horas, e duração de um ano.
Aos dezesseis anos, iniciei um estágio na área de suporte a servidores Unix,
tornando-me efetivo alguns meses depois. Aos dezoito anos, fui para uma empresa
para desenvolver uma plataforma de ensino à distância para uma escola de inglês.
Aos dezenove, ingressei no curso de Licenciatura em Matemática do Instituto de
Matemática e Estatística (IME) da Universidade de São Paulo (USP), pois gostava de
matemática e gostaria de lecionar. Mas mesmo durante o curso de matemática eu fazia
matérias de computação, até que um ano e meio depois, fiz transferência para o curso
de Ciênica da Computação, pois eu gostava mais do que a matemática em si.
Profissionalmente, neste mesmo período, me tornei empreendedor, com uma
empresa de serviços gráficos, sites e sistemas para a web. Hoje, faço trabalho apenas
nas horas livres como analista desenvolvedor web.
Neste capítulo irei destacar as minhas impressões pessoais sobre este trabalho
supervisionado de formatura, os desafios e frustrações encontrados, a importância das
disciplinas de graduação e uma breve discussão sobre o curso de CIência da
Computação.
7.1. Trabalho de Formatura Supervisionado
Entrei em contato com a dívida técnica pela primeira vez noinício de 2012 com a
aluna de doutorado, Graziela Tonin, que está fazendo seu trabalho relacionando dívida
técnica e métodos ágeis.
86
Fiquei muito entusiasmado com esta área e resolvi fazer meu trabalho
supervisionado de formatura dentro desta área. Então, junto com o prof. Dr. Alfredo
Goldman e a Graziela Tonin, desenvolvemos este projeto que visou realizar um estudo
da dívida técnica, analisar os métodos de identificação, medida e monitoramento da
dívida técnica e aplicá-los em projetos de software livre.
7.1.1. Desafios e Frustrações
Os principais desafios que encontrei neste projeto foi conseguir encontrar textos
base para apoiar o desenvolvimento deste trabalho. Muitas vezes, foi necessário
relacionar diferentes textos a fim de conseguir uma base melhor e que viabilizasse o
projeto.
Além disso, conseguir encontrar, instalar, utilizar e adaptar as saídas das
ferramentas para serem utilizadas para realizar a identificação da dívida técnica é um
desafio.
Uma grande frustração foi não conseguir encontrar alguma ferramenta gratuita
que pudesse ser utilizada de forma eficiente para realizar a identificação, medida e
monitoramento da dívida técnica.
7.1.2. Aplicação
Muitas disciplinas do curso foram utilizadas para realizar este trabalho algumas
diretamente, tais como engenharia de software, laboratório de engenharia de software
e laboratório de programação extrema. Além disso, outras disciplinas ajudaram de
forma indreta, tais como programação linear, laboratório de programação I e II e
sistemas de banco de dados.
Os detalhes de como estas disciplinas ajudaram no desenvolvimento deste
trabalho estarão expostas na sessão 7.2.1. Disciplinas.
7.1.3. Perspectivas Futuras
Para continuar as atividades os próximos passos que tomaria, não necessariamente
nesta ordem, seriam:
● Criar um plugin livre para o Sonar Qube para realizar a análise da dívida técnica,
87
● Aplicar os métodos de identificação, medida e monitoramento em outros
projetos, incluindo projetos de empresas.
● Acompanhar junto com equipes de desenvolvimento a evolução da dívida e
verificar ações que podem ser tomadas a fim de controlá-la.
7.2. BCC / IME-USP
O curso de Ciência da Computação me ajudou principalmente com uma ótima
base teórica. Além disso, a formação matemática que é proporcionada junto com o
curso me ajudou muito a conseguir abstrair diversos problemas.
De um modo geral a formação no IME me ajudou em quatro áreas:
● Computação: oferecendo uma base teórica, uma base prática e diversas
tecnologias, indo deste a introdução até processos mais sofisticados. Irei
detalhar mais sobre as disciplinas na próxima sessão.
● Matemática: com as disciplinas de cálculo foi possível aprender diversas teorias
que nos permite analisar funções de um modo científico, permitindo que isso
seja utilizado em qualquer pesquisa. Já as disciplinas de álgebra nos fornecem
uma grande abstração principalmente com teoria de anéis e grupos. Além disso,
álgebra linear, nos ajuda a trabalhar com matrizes e espaços vetoriais, o que
muitas aplicações acabam utilizando como base.
● Estatística: apesar de termos apenas três disciplinas, elas são fundamentais
para que possamos analisar dados e conseguir inferir informações a partir deles,
ajudando diversas vezes na realização dos exercícios programas e sendo útil
para qualquer tipo de pesquisa, como este trabalho.
● Física: as disciplinas de física possuem uma abordagem mais prática, que
envolveu a identificação de uma situação, modificá-la para um caso desejado e
aplicação de formulas para se obter o resultado desejado. Ou seja, é uma
aplicação direta do conteúdo, algo diferente das disciplinas de matemática.
7.2.1. Disciplinas
Neste capítulo só irei detalhar a importância das disciplinas de computação tanto
para minha formação, quanto para a realização deste trabalho.
88
Primeiro irei destacar as disciplinas que possuem uma abordagem conceitual da
computação:
● Introdução a Computação: apesar de já programar, esta disciplina me
apresentou algumas técnicas que não conhecia, como por exemplo, as de
ordenação.
● Princípios de Desenvolvimento de Algoritmo: é a principal matéria básica, nela
são ensinados conceitos que são utilizados durante todo o curso, tais como:
recursividade, busca binária, ordenações mais eficientes e lista ligadas.
● Estrutura de Dados: esta disciplina me ensinou como analisar e criar estruturas
de dados, podendo estas serem utilizadas em diversos tipos de aplicações. As
estruturas ensinadas estão divididas em listas ligadas, filas e pilhas, árvores,
representações de conjuntos e estruturas abstratas de dados.
● Álgebra Booleana e Aplicações: é uma disciplina que ensina uma teoria de
grupos para uma álgebra específica, esta muito utilizado na computação,
principalmente em circuitos.
● Métodos Formais em Programação: nesta disciplina é ensinada lógica formal,
com cálculo proposicional e de predicados, sintaxe, semântica e métodos de
prova.
● Métodos Numéricos da Álgebra Linear: aprendemos a calcular diversos métodos
de álgebra linear como: decomposição LU, fatoração QR e Cholesky. Todos eles
levando em conta as limitações do computador, que são capazes de representar
apenas números finitos, tendo assim, que tomar cuidado com problemas de
arredondamento.
● Programação Linear: esta matéria é uma especificação de álgebra linear. Nela
aprendemos a resolver o problema de programação linear ou seu dual utilizando
o método simplex, podendo também realizar uma análise de sensibilidade.
○ Esta disciplina me ajudou a desenvolver um raciocínio para resolver
problemas de otimização de múltiplas variáveis, o que algumas vezes foi
utilizado neste trabalho.
● Conceitos Fundamentais de Linguagens de Programação: ensina ao aluno os
principais paradigmas das linguagens de programação e os conceitos
fundamentais relacionadas ao seu desenvolvimento.
89
○ Esta disciplina foi utilizada neste trabalho para poder diferenciar as
linguagens de programação e verificar os conceitos nela associados com
a dívida técnica.
● Algoritmos em Grafos: ensina as estruturas para representar grafos, algoritmos
para percorrê-lo, busca de caminhos mínimos e outros métodos para verificar a
validade de propriedades como ciclo e conectividade.
● Análise de Algoritmos: ensina a analisar a complexidade e a corretude de
algoritmos, utilizando ferramentas de matemática discreta. Ainda aprimora a
capacidade de projetar e descrever os algoritmos.
○ Esta disciplina foi utilizado neste trabalho para verificar a complexidade e
corretude dos métodos, principalmente os relacionados a identificação e
ao monitoramento da dívida técnica.
● Linguagens Formais e Autômatos: ensina sobre palavras, linguagens e
operações sobre linguagens. São apresentados autômatos finitos e infinitos e
expressões regulares que são todas representações de linguagens regulares. É
ensinado também linguagens livres de contexto e autômatos de pilha.
● Organização de Computadores: ensina sobre a arquitetura e organização de
computadores, iniciando nos primeiros computadores até chegar nos
dispositivos que são utilizados hoje em dia.
● Sistemas Operacionais: ensina os conceitos fundamentais dos principais
sistemas operacionais. Ainda faz uma introdução da evolução dos sistemas
operacionais, desde os primeiros computadores. Nesta disciplina, somos
incentivados a implementar funcionalidades em sistemas operacionais reais.
● Programação Concorrente: ensina soluções para os problemas clássicos de
concorrências de um modo incremental. Estas soluções são: exclusão mútua,
barreiras, semáforos e monitores que são construídos baseando-se em envio de
mensagens ou compartilhamento de variáveis e provêm a comunicação e
sincronização entre processos ou thread’s.
○ Esta disciplina foi utilizada neste trabalho para conseguir identificar dívida
técnica relacionada a violações de concorrência.
90
Agora irei destacar as disciplinas que possuem uma abordagem prática da
computação:
● Laboratório de Programação I: ensina os conceitos de programação em baixo e
alto nível, deste assembly até a análise sintática. A fixação dos conceitos é feito
através de projetos de implementação.
● Laboratório de Programação II: ensina os conceitos fundamentais das
linguagens de programação orientadas a objetos, tais como: herança,
encapsolumento e polimorfismo. Os conceitos também são fixados na prática,
através de projetos de implementação.
○ Esta disciplina foi utilizada neste trabalho, pois foi necessário analisar
diversos códigos orientados a objetos, além disso, o paradigma orientado
a objetos pode gerar dívida técnica, precisando de métodos específicos
principalmente para realizar a identificação e a medida.
● Sistemas de Banco de Dados: ensinam sobre a arquitetura de sistemas de
banco de dados e os algoritmos e linguagens envolvidas no seu uso e
administração. É ensinado, também, modelos conceituais de representação de
dados e é desenvolvido um projeto de banco de dados.
○ Esta disciplina foi utilizada neste trabalho para analisar o banco de dados
do Sonar Qube, onde foram feitos análises nos dados e no modelo
conceitual.
● Engenharia de Software: ensina as atividades relacionadas ao desenvolvimento
de software. Essas atividades são desde o desenvolvimento do conceito do
projeto, passando pela codificação até chegar a testes. Além disso, são
ensinadas técnicas gerenciamento de projetos de software e de suas equipes.
○ Esta disciplina foi utilizado neste trabalho, pois dívida técnica é uma
subárea de engenharia de software e toda a teoria desta área pode ser
aproveitada.
● Laboratório de Engenharia de Software: ensina na prática como aplicar os
métodos vistos em engenharia de software, vendo técnicas avançadas de
desenvolvimento de projetos de software. Além disso, essa disciplina é focada
em testes de software, tanto validação, quanto verificação.
91
○ Esta disciplina foi utilizada neste trabalho para compreender e definir os
defeitos que geram dívida técnica e estão relacionados aos testes de
software
● Laboratório de Programação Extrema: ensina a essência das metodologias
ágeis de desenvolvimento de software, em especial, utilizando a metodologia de
Programação Extrema. Muitas das técnicas dessa metodologia são aprendidas
na prática, aplicando-as no desenvolvimento de softwares reais.
○ Esta disciplina foi utilizado neste trabalho principalmente por causa das
técnicas de desenvolvimento ágil. Estas tentam garantir a qualidade do
projeto, sendo assim evitam a dívida técnica.
● Tópicos Especiais em Desenvolvimento Web: ensina técnicas de
desenvolvimento web baseadas na web 2.0. A disciplina foca em aplicativos web
que permitem a interação social e apresenta diversas tecnologias que podem
auxiliar no desenvolvimento de softwares para web.
○ Esta disciplina foi utilizada neste trabalho para estudar o Sonar Qube.
● Introdução a Programação de Robôs Móveis: ensina os conceitos fundamentais
de programação de robôs móveis utilizando kits robóticos educacionais. A
disciplina é motivada por competições, seguindo as regras das competições de
robótica.
● Princípio de Interação Homem-Computador: ensina os conceitos básicos de
interação homem-computador, desde o seu planejamento até a sua
implementação.
● Computação Móvel: ensina conceitos relacionados a computação móvel
distribuída, envolvendo problemas na comunicação, gerenciamento de dados,
projetos móveis e tecnologias. São tratados, também, mecanismos, protocolos e
metodologias para o desenvolvimento de software para dispositivos móveis.
Agora irei destacar as disciplinas que não possuem uma abordagem técnica,
mas ajuda no desenvolvimento acadêmico e pessoal.
● O Computador na Sociedade e Empresa: é uma disciplina ministrada
exclusivamente a cada dois anos pelo prof. Dr. Valdemar Setzer. Ela trata dos
92
problemas humanos e sociais decorrentes do uso de computadores e impacto
na sociedade e nas empresas. São aulas participativas, onde diversos temas
interessantes são tratados, sendo a aula conduzida de acordo com o interesse
dos alunos.
● Leitura Dramática: está matéria ajuda os alunos a melhorarem em relação a
problemas de inibição para falar em público e relacionamento. Ela trabalha
também a fala e a dicção, permitindo que o aluno se comunique melhor.
