Universidade Federal de Pernambuco – UFPE
Centro de Informática - CIn
Tópicos Avançados em
Engenharia de Software
Estimando custo-benefício do
uso das técnicas de refatoramento
Dupla:
Caio César Sabino Silva (ccss2@cin.ufpe.br) Lais Sousa de Andrade (lsa@cin.ufpe.br)
Professor: Paulo Borba (phmb@cin.ufpe.br)
Sumário
1. Introdução
2. Cenário da empresa 2.1. Empresa A 2.2. Empresa B
3. Avaliação da aplicação de técnicas de refatoramento 3.1. Técnica de refatoramento escolhida
3.2. Custos de utilização da técnica 3.2.1. Treinamento da técnica
3.2.2. Instalação das ferramentas de desenvolvimento 3.2.3. Mentoring da técnica
3.2.4. Detecção de problemas 3.2.5. Perda de produtividade inicial
3.3. Benefícios advindos da utilização da técnica
3.3.1. Geração de módulos independentes e aumento de produtividade 3.3.2. Geração de diferentes versões do sistema
3.3.3. Redução do custo de manutenção 3.3.4. Redução do tempo de correção de bugs 3.3.5. Redução do tempo de criação de testes 3.4. Estimativa ROI
3.4.1. Cálculo do ROI 3.4.2. Empresa A 3.4.3. Empresa B
1. Introdução
Nesta etapa, vamos levantar os custos e benefícios da utilização de uma técnica de refatoramento utilizada no projeto, assumindo que foi utilizada numa empresa de desenvolvimento de software, de modo a estimar se o uso de tal técnica é viável e tem uma boa relação de custo-benefício.
Para isso uma planilha será levantada sobre os valores de custo e benefício das técnicas para que se possa calcular o ROI e se possa comparar o custo-benefício da técnica utilizada no projeto. Isso será útil na estimativa de saber se vale a pena ou não a aplicação de tal técnica no cenário de empresa descrito e com a aplicação do projeto.
2. Cenário da empresa
Para se considerar relações de custo/benefícios iremos considerar dois cenários de empresa, de forma que podemos comparar como a técnica se sai melhor. No primeiro cenário, teremos uma empresa de porte maior, com um número maior de funcionários, enquanto que no segundo cenário veremos uma empresa de porte menor.
Consideraremos que ambas as empresas mostradas abaixo estão estudando aplicar a técnica num projeto onde há um certo número de clientes do mesmo sistema, cada um com um conjunto de funcionalidades específicas e que têm uma notável tendência a variar.
2.1. Empresa A
Quantidade de desenvolvedores 20 Quantidade de mentores 5 Quantidade de instrutores 2 Licença de Software (R$) 500 Salário de desenvolvedor (R$) 2000 Salário de mentor (R$) 3000 Salário de instrutor (R$) 40002.2. Empresa B
Quantidade de desenvolvedores 5 Quantidade de mentores 2 Quantidade de instrutores 1 Licença de Software (R$) 500 Salário de desenvolvedor (R$) 1500 Salário de mentor (R$) 2500 Salário de instrutor (R$) 30003. Avaliação da aplicação de técnicas de refatoramento
Nesta seção, uma técnica de refatoramento utilizada será escolhida e terá seus custos e benefícios de aplicação calculados. Há uma planilha em anexo com todo o custo, benefício e ROI estimado para o mesmo. Aqui apenas as escolhas dos valores serão explicadas.3.1. Técnica de refatoramento escolhida
A técnica de refatoramento escolhida foi a utilização de aspectos para separação dos varios concerns, podendo ser casos de uso, tratados pelo projeto. Essa técnica foi escolhida pois foi a que, por intuição, pareceu ter melhor relação custo-benefício para o projeto RGMS.
3.2. Custos de utilização da técnica
Nesta seção, os custos de utilização da técnica de orientação a aspectos serão descritos e explicados.
3.2.1. Treinamento da técnica
No treinamento dessa técnica, foi necessário que os instrutores, junto com os mentores, mostrassem aos desenvolvedores uma nova abordagem para o projeto, Orientação a Aspectos, que exige que cada funcionalidade nova que venha a ser implementada seja vista de maneira diferente pela equipe. Foi estimado um tempo de um a dois meses de treinamento.
3.2.2. Instalação das ferramentas de desenvolvimento
O custo de instalação nas máquinas das ferramentas, como o plugin do AspectJ e outras possíveis ferramentas, que já inclui os gastos com licenças de software estimados para cada empresa, foi estimado levando-se em conta também o tempo exigido dos desenvolvedores para organizar seus ambientes de desenvolvimento. Foi estimado que os mesmos, sob supervisão dos mentores, levaria até 1 mês para instalar todos os softwares necessários para todos os
desenvolvedores para o desenvolvimento, execução de testes e geração de versões do
produto final. Nesse período, estima-se que o tempo gasto pelo desenvolvedor para instalar
3.2.3. Mentoring da técnica
.
No mentoring dessa técnica, foram necessários de dois a três meses de
acompanhamento do desenvolvimento por parte dos mentores, que ajudavam a entender o
problema ou mostrar uma abordagem diferente onde a técnica poderia ser aplicada no projeto.
3.2.4. Detecção de problemas
No que diz respeito à detecção de problemas de modularidade e reuso, foi gasto um tempo de análise do código já feito, discussão entre os desenvolvedores e os mentores sobre como aplicar a técnica aprendida para melhorar a estrutura do projeto. Além disso, mais duas semanas em uma etapa de testes, com ajustes de testes e execução dos mesmos, e que inclui a verificação de preservação de comportamento de código após o refatoramento. No período de
seis meses de refatoramento, iniciando em cerca de 15%, a produtividade dos desenvolvedores caiu em função deste problema seguindo uma função linear. Após os
seis meses, assumiu-se que o valor estagnou em 2,5% pois durante os próximos meses, o código continuava sendo analisado, entretanto poucos problemas de modularidade são encontrados.
Função de queda de produtividade por detecção de problemas e refatoramento nos seis primeiro meses.
3.2.5. Perda de produtividade inicial
Quanto à perda de produtividade inicial com o uso da técnica são levados em conta o tempo de treinamento, mentoring e refatoramento do código, onde poucas novas funcionalidade são produzidas. Dessa forma, a produtividade nos quatro primeiros meses foi reduzindo a
partir de 30 a 40% numa regressão mais lenta inicialmente e mais rapidamente com o tempo.
Função de queda de produtividade nos seis primeiro meses.
3.3. Benefícios advindos da utilização da técnica
Nesta seção, os benefícios de utilização da técnica de orientação a aspectos serão descritos e explicados.
3.3.1. Geração de módulos independentes e aumento de produtividade
Quanto à quantidade de módulos independentes que passaram a existir no sistema, considerando-se que cada concern definido na fase de refatoramento foi separado em um ou mais aspectos, houve uma maior independência no sistema que facilitou na divisão de tarefas na implementação de novas funcionalidades, e aumentou a produtividade, uma vez que permitiu que mais módulos independentes fossem desenvolvidos em paralelo pela equipe, e até mesmo testados isoladamente, o que acabou deixando os erros encontrados mais localizados e fáceis de encontrar e corrigir. A produtividade no desenvolvimento de casos de uso, após os seis
primeiros meses de utilização da técnica, foi elevada para 45% de forma lenta no início e mais rapidamente com o tempo.
Evolução da produtividade de desenvolvimento de casos de uso nos seis primeiros meses
3.3.2. Geração de diferentes versões do sistema
Sobre a possibilidade de geração de diversos produtos com o mesmo projeto, com a criação de módulos separados e independentes ficou mais fácil separar partes de código para a geração de uma determinada versão quando necessário. Como a divisão do projeto em módulos foi feita já visando este benefício, os mesmo já foram implementados da maneira mais independente possível, de modo que removendo alguns destes módulos se obtém uma versão estável com apenas algumas funcionalidades a menos. Após esse refatoramento, pôde-se utilizar o mesmo modelo de desenvolvimento que contemplasse as versões de produtos para diferentes clientes. Dessa forma, os esforços no desenvolvimento das diferentes versões do produto foram unificados com o uso dessa técnica, de forma que cada particularidade de uma versão do sistema é tratada como um módulo ou aspecto a ser incorporado no projeto. O novo
modelo de desenvolvimento passa a ser capaz de atender a 10 clientes do mesmo produto, de forma que cada feature específica é tratada como um aspecto adicional e
independente que possa ser colocado ou não de acordo com o makefile. Supomos para isso que cada desenvolvedor gastava cerca de 15% do seu tempo semanal para lidar com algum ajuste do código, testes de versões do sistema que ocorra em função dos vários clientes diferentes a cada build semanal ou release. Dessa forma, em 2 meses, com o refatoramento, cada
programador deixou de gastar 15% do seu tempo para geração de diferentes versões para diferentes clientes, de forma que o custo agora é muito próximo de zero. Foi suposto o
crescimento linear, uma vez que consideramos que o refatoramento do projeto ocorreu de forma gradual e numa progressão constante módulos correspondentes aos casos de uso implementados anteriormente foram gerados do sistema.
Função de aumento de produtividade em função da eliminação da perda de tempo tratando versões diferentes do mesmo produto nos seis primeiro meses.
3.3.3. Redução do custo de manutenção
No que diz respeito ao aumento de manutenabilidade do sistema, com a divisão do mesmo em módulos independentes é possível se fazer a manutenção do produto por módulos e em paralelo, uma vez que não dependem entre si, trocando apenas aqueles necessários, sem ter que mudar o código em locais separados ou em partes de código que não envolvem diretamente aquele concern que está sendo modificado. Com isso a mudança fica bem mais controlada, mais fácil de testar isoladamente e menos propensa a gerar erros em outras funcionalidades diferentes do produto. Para cálculo dos custos, supomos que uma equipe com 1/ 5 da quantidade dos desenvolvedores: 4 na primeira empresa e 1 na segunda empresa fiquem alocados para a detecção e correção de problemas. Da equipe de manutenção, supomos que
em seis meses, 40% do tempo de cada integrante deixou de ser desperdiçado em termos das dificuldades de identificar ou corrigir erros relacionados à manutenção do sistema, evoluindo de forma lenta no início e mais rápida com o tempo.
3.3.4. Redução do tempo de correção de bugs
Em relação à redução do tempo de depuração do software, o percentual médio de
tempo gasto por programador com depuração que foi eliminado com o uso da técnica seguiu um crescimento similar à uma evolução até 20% de forma lenta no início e mais rapidamente à medida que o tempo cresce. Isso se deve ao fato de que após a utilização da
técnica, cada módulo separado facilita a identificação de erros uma vez que por ser independente dos demais diminui o espaço de busca de código com erro. Isso se torna ainda melhor quando os testes são realizados por módulo, de forma que muito mais provavelmente o erro se encontrará nos módulos que não passarem nos testes.
Evolução da redução do tempo de depuração nos seis primeiros meses
3.3.5. Redução do tempo de criação de testes
Quanto à redução do tempo de criação e maior efetividade dos testes, com módulos independentes há agora a possibilidade de criação de testes específicos para cada componente separado, de modo que um erro que antes exigia um teste mais bem elaborado para aparecer no contexto de execução agora pode ser mais facilmente localizado com testes simples de unidade. A produtividade dos criadores de teste era gasta em torno de 25 a 30% com análise mais elaborada do sistema para poder testar um caso de uso. Após o uso da técnica e padronização do desenvolvimento, o tempo gasto passou a ser de 5 a 10%. Sem mencionar que os testes se tornam mais efetivos e ajudaram a reduzir o tempo de depuração dos desenvolvedores. Dessa forma, vamos supor o crescimento da redução do tempo
percentual gasto como iniciando em 0 de forma lenta no início e mais rápido progressivamente até o valor de 20%. Consideraremos a equipe de teste como sendo 1/5 da
Evolução da redução do tempo de criação de testes nos seis primeiros meses
3.4. Estimativa ROI
Nesta seção, o cálculo do ROI será comentado, mostrando como foi feito e avaliando os resultados.
3.4.1. Cálculo do ROI
No documento xls anexado, temos uma planilha chamada [Custos] [WCA] para cada empresa, onde o custo no pior cenário foi calculado (superestimando os custos nos intervalos explicados na seção 3.2.) para os 10 primeiros meses. Similarmente, temos uma planilha
[Beneficios] para cada empresa.
Na planilha [ROI] para cada empresa, temos tanto o ROI em cada mês calculado como o ROI acumulado até aquele mês. Por exemplo: o ROI acumulado do sétimo mês leva em consideração todo o custo e benefício até o sétimo mês, enquanto que o valor normal só leva em consideração o custo e benefício do sétimo mês.
3.4.2. Empresa A
No oitavo mês, a utilização da técnica passou a ter bom rendimento para a empresa, tendo considerado o pior caso de custos. Após os 10 meses, o ROI chegou a 68,1% o que se mostra um bom valor.
3.4.3. Empresa B
O gráfico do ROI acumulado foi o seguinte:
No nono mês, a utilização da técnica passou a ter bom rendimento para a empresa, tendo considerado o pior caso de custos. Após os 10 meses, o ROI chegou a 30,4%.
3.4.4. Análise dos resultados
Com base nos dados levantados para as duas empresas, percebeu-se que num período de dez meses não é muito viável a adoção da técnica de utilização de aspectos para a empresa B, uma vez que só começa a se tornar vantajoso a partir do nono mês. Entretanto, se o período for maior, certamente é vantajoso a adoção da técnica por tal empresa.
Comparando os resultados entre as duas empresas, pode-se perceber que numa empresa maior, que trabalha de forma mais sistematizada, com um número maior de funcionários, o cálculo do ROI acumulado mostrou que a técnica de utilização de aspectos trouxe um impacto maior, uma vez que se torna mais nítida a necessidade de que o código seja mais fácil de depurar, de se identificar onde um caso de uso é tratado, de se criar testes localizados e poder gerar versões que atendam a múltiplos clientes. Esses benefícios que a técnica de aspectos trouxe ao sistema, foram graças ao aumento de modularidade que tal técnica propiciou e que trouxe uma melhoria na produtividade do desenvolvimento de software da empresa.
