ROUGH DRAFT authorea.com/117224
Main Data History
Export
Show Index Toggle 0 comments
  •  Quick Edit
  • Gerência da Evolução Contínua: Dívida Técnica

    Abstract

    A necessidade de gerar produtos e soluções de software de forma adequada à expectativa do cliente resultou na adaptação dos formatos de entrega de software, para que esse possa ser feito de forma contínua, sem que haja dependências relacionadas a outras possíveis entregas que poderiam atrasar o que é de fato prioritário. Ferramentas que apoiam o desenvolvimento de software foram adequadas ou desenvolvidas para suportar esse fim, assim como o processo do desenvolvimento também teve de ser adaptado. Com isso, decisões devem ser tomadas nas mais diversas atividades do processo de desenvolvimento e podem gerar dívidas futuras, pois o escopo completo é desconhecido. Esse trabalho busca descobrir as influências da Engenharia de Software Contínua [ESC] na geração e percepção dos variados tipos de dívida técnica [DT] presentes na literatura, levantando hipóteses e indícios sobre essa relação. Serão propostos experimentos e outros estudos que possam validar as hipóteses feitas, ou para que os possíveis erros decorrentes da atribuição dessas hipóteses sejam identificados.

    Introdução

    Os projetos de desenvolvimento de software, assim como os projetos de outras áreas de conhecimento, são na maioria das vezes realizados considerando-se valores finitos de tempo e recursos, sejam eles dinheiro, pessoas, equipamentos ou outros. Desse modo, um mau gerenciamento do tempo e dos recursos gera como consequência produtos de má qualidade, com menos possibilidades de manutenção e evolução, quando comparados com produtos de alta qualidade (Lehman 1985).

    A metáfora de dívida técnica foi criada como forma de melhor entender e administrar as decisões que impactem de alguma forma a manutenibilidade do software. Adotar tal metáfora no fluxo de desenvolvimento do software ajuda os profissionais da área a melhor compreender e investigar problemas decorrentes dessas decisões.

    Dentro do contexto das metodologias ágeis, a dívida técnica tende a ser superior quando comparada com a de metodologias de desenvolvimento mais convencionais, uma vez que é característico entre as práticas a indefinição do escopo e das prioridades futuras do projeto a cada entrega incremental (Holvitie 2014). Por outro lado, nas práticas mais convencionais de desenvolvimento tanto o escopo quanto as prioridades do projeto já são definidas com uma antecedência maior, portanto há menos inclusão de requisitos desconhecidos, auxiliando na tomada de decisões antecipadas, tendendo a reduzir a dívida técnica.

    A união das metodologias ágeis com o conceito do lean development criou uma nova tendência na indústria, conhecida como engenharia de software contínua, conjunto de práticas nas quais as iterações com duração fixa e pré-definida previstas nas metodologias ágeis mudam para atividades com menor duração possível (e variável), ou seja, o projeto de software sofre evoluções constantes. Cada desenvolvedor não fica mais preso ao ciclo da iteração, podendo incorporar o seu trabalho ao projeto sempre que necessário, possibilitando um menor time-to-market.

    De posse dos diferentes tipos de dívida técnica presentes na literatura para ambientes ágeis ou mais tradicionais de desenvolvimento, este trabalho busca analisar de que forma cada tipo de dívida técnica se relaciona com as diferentes práticas da engenharia de software contínua, buscando indícios sobre cada um dos relacionamentos.

    O presente estudo está dividido em quatro itens, além desta introdução: o item 2 apresenta uma fundamentação teórica sobre as definições de dívida técnica e da engenharia de software contínuo; o item 3 apresenta as diferentes formas de classificação de dívida técnica com base nos estudos pesquisados; o item 4 apresenta a classificação das atividades da engenharia de software contínua; o item 5 apresenta o relacionamento entre os dois conceitos; o item 6 detalha as pesquisas realizadas em busca de indícios na literatura; e o item 7 trata das considerações finais sobre o trabalho e indica possíveis estudos futuros.

    Revisão Literatura

    Este item tem por objetivo apresentar a revisão feita pelos autores na literatura disponível sobre os assuntos discutidos no trabalho. Para a pesquisa foi utilizada a plataforma Scopus.

    Dívida Técnica

    O termo foi cunhado pela primeira vez por Ward Cunningham (Cunningham 1993), ao tentar explicar ao seu cliente - da área financeira - sobre a decisão que estava tomando durante uma refatoração no produto. Desde então, por ser uma metáfora, o termo tem sido utilizado de diversas formas, nem sempre quando realmente deveria ser aplicado.

    Durante a pesquisa foram encontradas diversas definições diferentes para dívida técnica. Wiklund et al (Wiklund 2012) definem como a diferença entre o estado atual e o estado ideal do sistema, no entanto essa definição pode significar por exemplo um conjunto de defeitos no software que não foram identificados durante o desenvolvimento, e não apenas a dívida técnica do software.

    Fitzgerald e Stol (Fitzgerald 2015), por sua vez, descrevem dívida técnica como o adiamento de questões potencialmente problemáticas para uma fase posterior, ao invés de tratar imediatamente. Entretanto uma dívida técnica pode ser formada por questões não necessariamente problemáticas, como por exemplo um recurso que não precisa ser implementado no momento da tomada de decisão.

    Já Oliveira et al (Oliveira 2015) explicam que dívida técnica é a ocorrência de artefatos imaturos, incompletos ou inadequados àquele momento do ciclo de desenvolvimento de software. Essa definição pode caracterizar outro tipo de fenômeno. Pela metáfora proposta por Cunningham (Cunningham 1993) a dívida gerada seria uma ação a ser realizada posteriormente, e não menciona em nenhum momento a questão da adequação ou maturidade dos artefatos em um determinado momento.

    Brown et al (Brown 2010) apresentam uma definição mais próxima da metáfora proposta por Cunningham. Segundo eles, a dívida técnica surge em uma situação em que a qualidade do código a longo prazo é negociada para o ganho a curto prazo, criando uma pressão futura para remediar o que ficou pendente. Apesar de fiel à proposta inicial da metáfora, atualmente é sabido que um produto de software abrange muito mais que o código, sendo composto pelo projeto, planejamento, manutenção, testes e inúmeros artefatos.

    Dessa forma, Spínola et al (Spínola 2013) e Zazworka et al (Zazworka 2014) apresentam uma ampliação do conceito de dívida técnica, tratando não somente como um fenômeno de código. Eles a definem como a contextualização de uma escolha onde, deliberadamente, decide-se postergar uma ação, para que haja um ganho a curto prazo mas que será posteriormente pago e com juros. O resultado dessa decisão é observado em atrasos inesperados ao realizar alterações necessárias e na dificuldade em manter um nível aceitável de qualidade para o projeto. Apesar de ser uma definição mais satisfatória, definir a dívida técnica com termos como “atrasos” ou “deliberadamente” pode limitar a possibilidade de aplicação e entendimento do fenômeno.

    Em 2016, um seminário que aconteceu na Schloss Dagstuhl, em Leipzig (Alemanha) (Avgeriou 2016), desenvolveu entre os seus participantes uma definição mais recente sobre dívida técnica. Segundo concluíram no seminário, em sistemas intensivos de software um item de dívida técnica é um construto de design ou de implementação que é eficaz no curto prazo, mas cria um contexto técnico no qual uma futura modificação pode se tornar mais custosa ou até mesmo impossível. Este item pode apresentar um risco de contingência cujo impacto é limitado à qualidade interna do sistema, principalmente manutenibilidade e a capacidade de evolução do sistema.

    Adicionalmente, o seminário avançou na questão mais geral da dívida em projetos de software, abordando questões que não são classificadas necessariamente como técnicas, mas que estão presentes durante a concepção, o desenvolvimento e manutenção do software. A dívida social em um produto de software, por exemplo, pode se fazer presente quando é decidido abrir mão de certos recursos de acessibilidade, sabendo que no futuro tais recursos podem ser necessários para o uso adequado do software.

    É importante destacar que a dívida, seja ela técnica ou não, não precisa estar associada a uma falha no software. O software funciona normalmente mesmo possuindo uma dívida, ou seja, ele atende aos requisitos funcionais e não-funcionais estabelecidos no início do projeto.

    Também cabe aqui destacar uma questão inerente à língua portuguesa. O termo original em inglês, debt, possui vários significados distintos. Ao traduzir para o português, surgem dois termos complementares que traduzem debt: dívida e débito. Podemos definir então o débito como o item que não foi adotado para o projeto de software no momento da tomada de decisão. A dívida, por sua vez, pode ser considerada como os “juros” a serem pagos no futuro, ou seja, todo o esforço necessário (podendo ser tempo, recursos financeiros, pessoais, etc.) para a quitação do débito tomado no momento da tomada de decisão.

    A Dívida Técnica em ambientes ágeis

    Pouco se tem publicado na literatura científica sobre a relação entre dívida técnica e os elementos da engenharia de software contínua, como a integração contínua ou a evolução contínua. No entanto, a dívida técnica e as metodologias ágeis possuem uma estreita relação.

    Parte dessa relação surge por conta da necessidade de se não possuir uma visão do todo em um projeto que adota uma metodologia ágil. Normalmente o planejamento dos incrementos é feito em partes, e nem sempre os envolvidos no processo de desenvolvimento possuem noção do que deverá ser feito nos incrementos posteriores, ou qual será a ordem dos elementos a serem desenvolvidos (Holvitie 2014). Sendo assim, sempre que há uma tomada de decisão em relação a alguma solução técnica a ser implementada, aquela que gera um maior benefício no curto prazo (ou seja, naquela iteração) é adotada. Essa ação é, pela definição, uma potencial geradora de dívida técnica, mesmo que involuntária.

    Holvitie (Holvitie 2014) elaborou um survey com a indústria finlandesa com o objetivo de analisar o efeito da adoção dos métodos ágeis sobre a dívida técnica de um projeto. Entre os seus resultados, foi observado que as práticas cujos efeitos são melhor percebidos na dívida técnica são as de padronizações de código, refatoração e integração contínua. Além disso, os processos cujos efeitos são melhor percebidos na dívida técnica são as revisões/retrospectivas de iterações, as iterações em si e as reuniões de planejamento das iterações. Finalmente, o survey também avaliou em quais componentes de projeto a dívida técnica é mais visivelmente presente. Segundo a pesquisa, isso se dá na fase de implementação, ou seja, durante o desenvolvimento do código.

    Apesar de o survey indicar que a implementação é o principal componente de projeto onde se observa dívida técnica, isso não significa que a dívida é gerada naquele momento. Sabemos que o código é reflexo do desenvolvimento do projeto como um todo, que engloba diversas fases e artefatos distintos, como requisitos e modelos UML. Sabemos também que muitas das funcionalidades inseridas em um software podem ter origem externa à equipe de projeto, sendo uma decisão mais estratégica a nível corporativo do que técnica. Dessa forma, podemos afirmar que a geração da dívida está distribuída ao longo de todo o processo de desenvolvimento do software.

    Engenharia de Software Contínua

    Da necessidade de realizar entregas cada vez mais frequentes, atender a demandas externas da área de negócios e com a criação e evolução do uso de SaaS (Software as a Service), ou software como