UVT
Como resultado das atividades de Reengenharia de Software, os aplicativos que anteriormente estavam acoplados ao sistema legado do UVT, agora têm uma melhor componentização, favorecendo assim o isolamento das lógicas de negócios das interfaces do consumidor. Isso representou uma maior portabilidade, reuso e uma melhoria significativa na manutenção do software. Isso é perceptível quando analisamos as métricas de qualidade do sistema migrado, obtidas pela uso da ferramenta “NDepend” 1.
A Tabela3 apresenta os resultados comparativos da dívida técnica entre o sistema legado e o sistema migrado em termos de Categorias de correção, do Esforço (em dias, horas e minutos), de Custo (em R$) e quantidade de Correções 2.
Tomando por base os resultados obtidos pela análise estática de código, obtivemos uma redução significativa da dívida técnica no código migrado. Analisando a Tabela
3, podemos notar a redução em 58% na quantidade de correções necessárias. O esforço necessário para realizar todas essas correções saiu de um patamar de 267 dias para 48 dias, o que significou uma redução no custo de R$ 107 mil para R$ 19 mil.
Podemos notar ainda que na base de código migrado correções da categoria .Net
Framework / System.Threading já não são mais computados. Esse recurso do framework é
utilizado para criação de processamentos paralelos, geralmente associados a rotinas execu- tadas em background. A ausência de ocorrências nessa categoria se deu pela transferência desse tipo de operação dos serviços web para infraestruturas de processamento assíncrono mais apropriadas.
1 A ferramenta NDepend foi aqui utilizada para demonstrar valores totais da dívida técnica, bem como
categorizar os tipos de correção associados a essa dívida. Sua escolha se deu também pelo fato de se basear na SQALE method (http://www.sqale.org/details) e sua análise é feita sobre a Intermediate language (IL) do .net framwork, abarcando assim todas as linguagens da família .net framework (C#, Visual Basic e F#) sob uma mesma ótica de análise (https://www.ndepend.com/)
2 O esforço é obtido pela relação de número homen-dia para desenvolver 1000 linhas de código. Por
padrão a ferramenta adota a relação 18 homens-dia, o que significa em média 55 linhas de código escritas por desenvolvedor em um dia
Tabela 3 – Dívida técnica do sistema UVT antes e depois da migração.
Código Legado Código Migrado
Categoria Esforço Custo Correções Esforço Custo Correções
.NET Framework
System 6h45min 338 33 1d3h 596 36
Collection 2h10min 108 13 1d 408 49
Globalization 3d1h 1.25K 179 1d6h 742 105
Reflection 6h30min 325 39 1h50min 38 11
InteropServices 35min 29.2 7 30min 25 6
System.Threading 40min 33.3 1 - - -
System.Xml 3h50min 192 23 4h 200 24
Project Rules
Architecture 176d 70.6K 737 8d 3.21k 135
Code Smells 51d 20.6K 273 22d 8.87k 301
Dead Code - - - 6h30min 325 37
Design 4d1h 1.65K 449 4d5h 1.86k 363
Immutability 17d7h 7.17K 889 6h32min 327 53
Naming Conventions 1h25min 70.8 66 3d1h 1.29k 249
OOP Design 8d5h 3.46K 837 2d4h 1.05k 610
Source Organization 3h45min 15 188 7h 350 28
Visibility 2d4h 1.02K 656 4h22min 219 421
Total 267d 107K 4217 48d 19.6k 2428
Registramos também a diminuição expressiva de necessidade de correções na categoria Architeture de 176 dias para 8 dias. Antes nessa categoria a regra “Camada de
interface do usuário não deve usar diretamente a camada DAL” apresentava 470 ocorrências
(ver 2), marcando uma dívida de 155 dias, sob um custo de R$ 62 mil; agora na base de código migrada essa regra apresenta apenas uma ocorrência de 32 min, sobre um custo de R$ 26,7.
Métricas como Code Smells, Immutability, OOP Design, Visibility também apresen- taram diminuição da dívida. Isso indica que do ponto de vista da Reengenharia a migração do software foi conduzida de modo a desenvolver código com melhor qualidade. Por outro lado, métricas do tipo Naming Conventions, Source Organization e Design apresentaram um relativo aumento. Além dessas métricas, também houve o registro na base de código migrada, de ocorrências da categoria Dead Code. Isso pode indicar problemas na gestão do código-fonte migrado, principalmente devido a sua granularidade e decomposição.
Para efeito de comparação dessa granularidade, a Tabela4apresenta as métricas de LoC do sistema UVT antes da migração e dos Inventários de serviços criados no processo de reengenharia. Nessa tabela, a coluna Avaliação apresenta uma escala de classificação de sustentabilidade relacionada ao valor do índice de dívida técnica no projeto. Essa
classificação é baseada na relação entre o tamanho da base de código e o tempo estimado para corrigir todos os problemas identificados. A classificação “A” indica que o custo de correção pendente é menor que 5% do tempo estimado para correção, enquanto uma classificação de “C” indica que esse custo está entre 11% e 20%. Já a coluna #LOCs apresenta o número de linhas de código.
Tabela 4 – Métricas de LoC no código legado Vs código dos Inventários.
Avaliação UVT #LOCs
C Legacy Code 282K
Avaliação Inventário #LOCs
A Arrecadação 43K A Documentos Fiscais 39K A Cadastro Fiscal 29K A Transportadoras 24K A Fiscalização 41K A Atendimento 11K A Autenticidade 22K A Extrato Fiscal 11K A Parcelamentos 27K 247K
Podemos notar que o código legado do sistema UVT tem a classificação “C”, por sua vez, os inventários foram avaliados na classificação “A” na escala de classificação de sustentabilidade, o que indica uma dívida técnica muito baixa. Também é possível notar que o número total de LoC em Inventários de serviço (247K) aproxima-se ao número de LoC do sistema legado (282K). No entanto, como cada Inventário possui um ciclo de manutenção independente, esse número cai consideravelmente.
Além das métricas de código, foram extraídas do ambiente de produção, métricas de desempenho dos serviços implantados. A Tabela 5apresenta alguns indicadores obtidos por meio da infraestrutura de monitoramento ELK, do desempenho dos serviços. Essas métricas foram extraídas entre os meses de Junho e Dezembro de 2017, e foram agrupadas por quantidade total de requisições (#Requests) no mês, tempo médio de resposta (em milissegundos) de todos os serviços e a quantidade de usuários (#Users) atendidos.
Nesse período, o projeto piloto da UVT foi lançado oficialmente em junho/2017 para uma base de usuários inicial com menos de 1.000 usuários. Em julho/2017 a base de usuários foi substancialmente expandida (mais de 4.000 usuários), e enquanto o número de requisições mais que dobrou (484.665 requisições contra 197.458 do período anterior); o tempo de resposta permaneceu em torno de 200 milissegundos. Em agosto/2017, houve um pequeno aumento no número de usuários (mais de 5.000 usuários) e no número de requisições (652.455) com um tempo de resposta médio estável (199,21 milissegundos).
Tabela 5 – Resultados da eficiência de desempenho dos serviços). Month #Requests Response time (ms) #Users
Jun/2017 197,458 222,00 939 Jul/2017 484,665 184.92 4,079 Aug/2017 652,455 199.21 5,162 Sep/2017 3,889,923 187.69 11,156 Oct/2017 4,039,758 242.07 11,347 Nov/2017 4,286,200 204.58 15,301 Dec/2017 4,447,635 203.31 14,519
Até agosto/2017, tanto o sistema legado quanto o novo sistema estavam ativos paralelamente. No entanto, em setembro/2017, o sistema antigo foi desativado e a partir desse momento todos os usuários passaram a consumir serviços no novo sistema UVT. Dessa forma, tivemos um incremento de 116% na base de usuários (de 5.162 usuários para 11.156 usuários) e um incremento de 496% no número de requisições (de 652.455 solicitações para 3.889.923 solicitações).
Este foi um momento de apreensão para a equipe, mas apesar do enorme aumento na carga, o tempo médio de resposta permaneceu estável em torno de 200 milissegundos. Além disso, os feedbacks recebidos pela equipe era de que havia uma sensação positiva em relação ao desempenho do sistema como um todo, bem como havia feedbacks de aceitação das nova interface gráfica do sistema Web e dos aplicativos para dispositivos móveis. Nos meses seguintes, de outubro/2017 a dezembro/2017, o sistema apresentou um aumento de 557.712 requisições e 4.145 usuários. No entanto, o desempenho permaneceu próximo de 200 milissegundos.
É importante mencionar que entre os meses de junho/2017 e dezembro/2017, a equipe de operações estava monitorando ativamente todo o ambiente como parte das atividades da fase de implantação. Isso permitiu a identificação de gargalos na infraestrutura e a realização de algumas mudanças pró-ativas, como o redimensionamento de recursos de infraestrutura alocados para bancos de dados e serviços de cache, bem como a inclusão de novas instâncias de serviços.
6.2
Resultados da adoção de SOA
A aplicação do SPReaD para orientar o projeto de migração de sistemas forneceu a SET benefícios substanciais como o alcance do Service Aware Level, um dos níveis de ma- turidade de organizações orientadas a serviços. Ao atingir esse nível, foi confirmado que os requisitos e metas de negócios relevantes estão definidos e que a base organizacional global necessária para a iniciativa de SOA está em vigor. Nesse sentido, é possível afirmar que a
SET atingiu esse nível de maturidade uma vez que os Auditores demandantes de solicitação já apresentam um nível de compreensão sobre a arquitetura de serviços adotada pela SET em seus projetos, bem como utilizam junto com os analistas de TI o repositório de serviços como ferramenta para compor em suas requisições serviços agnósticos já existentes na base de Inventários de serviços. Além desse benefício geral, adoção do SOA trouxe resulta- dos positivos que impactaram o ciclo de vida de desenvolvimento de software da SET como:
Contrato de Serviço Padronizado: A partir das atividades de modelagem e constru-
ção de serviços, foram adotadas abordagens que promoveram a geração de uma série de metadados que auxiliam na formalização de contratos dos inventários de serviços e na descoberta de capacidades associadas a eles.
Monitoramento de serviço em tempo real: A necessidade de monitorar o estado dos
serviços motivou uma mudança nas operações de suporte. Antes da migração, a equipe de TI trabalhava em uma abordagem reativa aos incidentes gerados pelo sistema. Com a adoção desse monitoramento ativo, a equipe adotou uma postura mais preventiva, pois o acesso às informações da operação e às falhas de serviço é monitorado a partir de um painel de controle, em tempo real.
Monitorando a dinâmica dos negócios: Com o resultado do monitoramento de ser-
viços em tempo real, também foi possível entender a dinâmica do negócio a partir do consumo de recursos por parte dos auditores, contribuinte, cidadãos etc. Também foi possível medir o impacto desse uso na infraestrutura computacional do SET.
Alinhamento entre TI e negócios: Como resultado da criação do Repositório de
Serviços, os auditores e desenvolvedores da SET agora possuem uma base na qual podem localizar serviços agnóstico com os quais podem definir novos processos de negócios em conjunto. Isso motivou os auditores a redefinirem seus processos de especificação de requisitos e organização de projetos, o que pode ser observado pela busca por ferramentas como BPM e o interesse em colaborar com a organização dos serviços através da construção de um catálogo de serviços da SET.
Os resultados obtidos foram apresentados aos analistas de negócios e à equipe gerencial da SET, com reações muito positivas por parte da gestão da CODIN (Coordena- doria de Informática) e do Secretário de Tributação, que foram convidada pelo BID para a apresentar em um evento regional o projeto de migração do UVT como um dos caso de sucesso de destaque, pelo cumprimento do prazo e gestão eficiente dos recursos.
soluções de software, uma vez que o paradigma SOA está consolidado e trouxe benefí- cios como agilidade da organização em resposta as demandas de mercado, o retorno de investimento pela reutilização de serviços e a diversificação de fornecedores de tecnologia. Tudo isso tem impacto na eficiência da arrecadação do estado do Rio Grande do Norte. Além disso, existem novas demandas para aplicação de SPReaD para outros sistemas de SET, e um novo projeto está sendo executado (atualmente na fase de modelagem de nosso processo).
7 TRABALHOS RELACIONADOS
Este capítulo apresenta alguns trabalhos da área relacionados aos problemas explorados nesta pesquisa. Nesse sentido, os trabalhos citados a seguir são relatos sobre a migração de sistemas legados, aplicação de SOA em contextos de Governo eletrônico (e-gov), o uso de MSOAM como metodologia para projetos SOA e microsserviços.