Uma Estratégia para Substituição de Sistemas Legados - PDF
Uma Estratégia para Substituição de Sistemas Legados
Download "Uma Estratégia para Substituição de Sistemas Legados"
Mirela Capistrano Mendes
1 Uma Estratégia para Substituição de Sistemas Legados Danuza Ferreira S. Neiva¹, Ecivaldo de Souza Matos² ¹ Departamento de Ciência da Computação Universidade Federal da Bahia, Salvador, BA-Brasil ² Departamento de Sistemas e Computação Universidade Federal de Campina Grande, Campina Grande, PB Brasil Abstract. Legacy systems are critical and old applications, characterized for a deficient structure and having suffered many updates. A solution is their substitution, but it involves some aspects of risks as cost, time and change of paradigm. This critical scene almost always is a consequence of the Software Engineering practices adopted, demanding more care with the reengineering of all the business processes and with the software development. Moreover, this article presents a strategy for the substitution of legacy systems, using agile practical and changes management and the knowledge management. It s the result of a work of conclusion of graduation course in Computer Science in the Federal University of Bahia. Resumo. Sistemas legados são aplicações críticas e antigas, caracterizadas por uma deficiente estrutura e por terem sofrido muitas atualizações. Substituí-los é uma solução normalmente adotada, mas envolve vários aspectos de riscos como custo, tempo e mudança de paradigma. Este cenário crítico, na maioria das vezes, é conseqüência das práticas de Engenharia de Software adotadas, exigindo cada vez mais cuidados com a reengenharia de todos os processos de negócio e com o desenvolvimento do produto de software. Diante disto, este artigo apresenta uma estratégia para a substituição de sistemas legados, utilizando práticas ágeis e gerenciamento de mudanças e do conhecimento, resultado de um trabalho de conclusão de curso de graduação em Ciência da Computação na UFBA. Palavras-chave: Engenharia de Software, sistemas legados, metodologias ágeis. 1. Introdução As empresas tendem a investir cada vez mais em tecnologia no planejamento, execução e avaliação de seus processos, esperando obter um retorno prolongado dos seus investimentos. Segundo Ian Sommerville (Sommerville 2003), o tempo de vida útil dos sistemas computacionais é muito variável, muitos sistemas de grande porte permanecem em uso por mais de dez anos. Muitos destes sistemas 1 são conhecidos como sistemas legados. Um sistema legado é um software antigo, crítico para o negócio, desenvolvido há alguns anos e que 1 O termo sistema é utilizado nesse artigo como sinônimo de software.
2 incorporou um grande número de alterações nas suas rotinas, freqüentemente com documentação desatualizada ou inexistente, sofrendo manutenção por vários anos. Portanto, é um software de fundamental importância para a regularidade dos processos da organização. Com efeito, por se tratar de uma aplicação crítica, qualquer falha pode refletir em sérios impactos nos negócios, conseqüentemente, o risco envolvido na substituição desse tipo de sistema é alto, o que leva a organização geralmente a optar por sua manutenção e não pela substituição. Contudo, quando o processo de substituição de sistemas legados trata de uma solução necessária, os seus aspectos de riscos devem ser analisados com cautela, como o custo, o tempo necessário para substituição, a mudança de paradigma na organização e o todo o impacto operacional causado pela implantação do novo sistema. O seu cenário crítico, na maioria das vezes, é conseqüência das práticas de engenharia de software adotadas, exigindo cada vez mais cuidados com a reengenharia dos processos de negócio, já que estes podem levar a mudanças na rotina organizacional, afetando inclusive a cultura organizacional. Temas correlatos são estudados pela disciplina de Engenharia de Requisitos, sendo notada uma carência de técnicas específicas para tratar as peculiaridades de um processo de substituição de sistemas legados, que envolve análise de requisitos, análise de riscos e custos das mudanças, além da administração de conflitos gerados com a mudança de paradigma. Neste contexto, este artigo apresenta uma estratégia específica para a substituição de sistemas legados baseada nas diversas metodologias e abordagens já tratadas na literatura da área, minimizando os problemas operacionais decorrentes da mudança e, conseqüentemente os seus riscos e custos. 2. Soluções para Sistemas Legados Estudos na área de sistemas legados têm identificado importantes problemas nos processos usuais de manutenção desse tipo de software. Segundo Ian Sommerville (Sommerville 2003), as dificuldades encontradas para manutenção de sistemas legados são conseqüências da falta de padronização na implementação de código, uso de linguagem obsoleta, documentação inadequada ou desatualizada, código-fonte de difícil compreensão, dados duplicados ou desatualizados, inexatos ou incompletos. A importância do sistema legado para a organização e a necessidade de mantê-lo em operação têm incentivado pesquisas na busca de soluções otimizadas para sua evolução. Tais soluções buscam prioritariamente evitar custos excessivos e manter o software em operação para continuar prestando os serviços corporativos essenciais. De acordo com Jesús Bisbal (Bisbal 1999), estas soluções são divididas geralmente em três categorias: Redesenvolver: reconstrução do sistema legado usando novo hardware e modernas arquiteturas, ferramentas e banco de dados. Ao final do processo de redesenvolvimento, a organização pode se encontrar com um sistema reconstruído baseado em uma tecnologia obsoleta.
3 Envolver: Consiste no reaproveitamento do que já existe, realizando melhorias, modificações de componentes e melhoria de interface. Migrar: converte um sistema existente para uma plataforma nova, retendo as funcionalidades do sistema legado e causando pouco rompimento no ambiente operacional e de negócio já existentes. Logo, pode-se observar que envolver é a estratégia que menos causa impacto no sistema legado, contudo depende da arquitetura desse sistema, que geralmente não é modularizada. O redesenvolver conduz a maioria das mudanças, porém é uma escolha de risco para a maioria das organizações. Dessa forma, a migração é uma solução intermediária entre envolver e redesenvolver, inclusive considerada mais amigável. Contudo, a estratégia a ser adotada depende da situação do sistema legado. Se as funcionalidades do sistema legado não atendem às necessidades da empresa e existem novas rotinas a serem envolvidas no sistema, um redesenvolvimento é o mais indicado. 3. Metodologias Ágeis O ambiente de desenvolvimento do software substituto do sistema legado é caracterizado por requisitos instáveis e desconhecidos. Na maioria dos sistemas legados existe um abismo entre a descrição documentada e as funcionalidades implementadas e realidade atual (Adolph 1996). A sua alta influência nos negócios da organização torna o processo de substituição arriscado, desejando-se um curto tempo de resposta. Diante deste cenário, a análise das metodologias vigentes é de grande relevância para a construção de uma estratégia para atender as necessidades desta substituição. As metodologias clássicas da Engenharia de Software tendem a tratar de uma mesma maneira os diferentes tipos de desenvolvimento de software. Consideram que na fase inicial de desenvolvimento de software os requisitos são previsíveis. Desta forma, o processo de desenvolvimento é prejudicado em ambientes em que as necessidades do cliente são instáveis ou não estão totalmente definidas. As metodologias em voga, em geral, são voltadas para grandes projetos e grandes equipes, com complexidade e burocracia aceitáveis e, às vezes, necessários para projetos desse nível. Os projetos de pequeno porte e com equipe reduzida podem ser orientados por metodologias mais simplificadas, que não causem tantos entraves para os pequenos times de desenvolvedores, com prazos cada vez mais curtos. Visualizando estes problemas, um grupo inicial de 17 pesquisadores, auto denominados de Aliança Ágil (Agile Alliance), iniciaram em 2001 uma discussão onde foi definido o Manifesto Ágil, cujo objetivo seria encorajar melhores meios de desenvolvimento de software, baseado nos seguintes valores (Manifest 2001): Indivíduos e interações valem mais que processos e ferramentas. Software funcionando vale mais do que documentação abrangente. Colaboração do cliente vale mais que a renegociação do contrato. Respostas rápidas a mudanças valem mais que seguir um plano. A prioridade que o Manifesto Ágil atribui a alguns valores não rejeita outras necessidades. Os processos e ferramentas, a documentação, a negociação de contratos
4 ou o planejamento são identificados como valores secundários em um processo de desenvolvimento de software. As metodologias que podem ser classificados como ágeis possuem em comum o fato de trabalharem em pequenos projetos, com requisitos instáveis, havendo priorização das pessoas e não dos processos, com relação constante com o cliente guiado pela fundamentação de que as pessoas devem trabalhar unidas e motivadas. Dentre as práticas e metodologias ágeis levantadas, foram analisadas e utilizadas neste trabalho as metodologias Scrum e Extreme Programming (XP). A Extreme Programming (XP) trata-se de uma metodologia de desenvolvimento de software que deve ser usada a todo tempo, e não em uma seqüência estática de procedimento (Beck 2000). É baseada nos valores de simplicidade, comunicação e feedback constante, reunindo toda a equipe sobre práticas simples, priorizando uma eficiente comunicação na equipe para que todos acompanhem e controlem o desenvolvimento. A Scrum é uma metodologia de gerência de projetos, orientada para flexibilidade, adaptabilidade e produtividade (Schwaber 1995). Com efeito, há foco nas pessoas, para que a equipe produza, de forma flexível, em um ambiente de constantes mudanças. Utiliza métodos ágeis, contudo, não adota explicitamente práticas de engenharia de software. Seu funcionamento consiste nas fases de planejamento, projeto arquitetural, desenvolvimento e encerramento. O desenvolvimento é realizado em ciclos iterativos, chamados de sprints, acompanhados de reuniões de revisão periódicas. A Scrum e a XP são complementares, pois Scrum provê práticas ágeis de gerenciamento, enquanto XP provê práticas integradas de engenharia de software. O fato de Scum e XP trabalharem com equipes pequenas possibilita um maior controle do gerenciamento de tarefas, propiciando uma maior produtividade. A escolha destas metodologias foi influenciada pelos seguintes fatores: - As metodologias Scrum e XP, consideram a imprevisibilidade, adotando práticas ágeis e flexíveis. O processo se adapta ao ambiente incorporando as inúmeras mudanças no decorrer do projeto. (Schwaber 1995; Soares 2004). - são amplamente conhecidas e cada vez mais utilizadas no desenvolvimento de software de pequeno e médio portes. (Wuestefeld 2001;Schwaber 1995); - possuem documentação suficiente para o aprofundamento dos estudos; 4. Estratégia para Substituição de Sistema Legado A Estratégia desenvolvida busca solucionar os problemas dos sistemas legados através da substituição de software, que pode ser um caso de migração ou redesenvolvimento, como visto na Seção 2. Fundamentada principalmente pelas práticas ágeis da Scrum, a Estratégia possui os seguintes elementos de controle no processo de desenvolvimento: Product BackLog: atividades definidas no planejamento para construir o produto final. É constituído de uma lista, que contém inicialmente as funcionalidades do sistema legado a serem implementadas. A cada iteração novos itens são incrementados, podendo ser requisitos ou atividades necessárias para o desenvolvimento. A lista pode ser composta por funcionalidades, manutenção corretiva, melhoramentos solicitados
5 pelo cliente, aprimoramento para uma maior competitividade do produto no mercado, atualizações de tecnologia, entre outros. À medida que os itens forem trabalhados serão excluídos do Product Backlog. A Figura 1 mostra as diversas origens do Product BackLog. Figura 1 - Origens que constituem o Product Backlog Sprint: é um conjunto de atividades de desenvolvimento conduzidas durante um período predefinido, usualmente de uma a quatro semanas. A fase de desenvolvido é composta por ciclos iterativos que implementam um conjunto de itens de backlog definidos no planejamento. Cada iteração corresponde a um sprint. Release: grupo de itens do backlog que serão trabalhados num conjunto de iterações. Ao fim desse conjunto de iterações tem-se uma versão estável do produto. A liberação dessa versão considera fatores como qualidade e necessidade do cliente. Contudo é importante identificar no processo de desenvolvimento a diferença entre release e versão. Considerando esses elementos fundamentais, o processo de substituição é dividido nas seguintes fases: a) Pré-desenvolvimento. b) Desenvolvimento. c) Pós-desenvolvimento. Tendo em vista o seu caráter evolucionário, o novo software é projetado para não repetir os erros identificados no sistema legado, evitando substituí-lo mais à frente por um outro software, por motivos similares ao da substituição atual Pré-desenvolvimento O pré-desenvolvimento é dividido nas etapas de Reengenharia e Planejamento, descritas a seguir Reengenharia Normalmente, a equipe que desenvolverá o novo sistema não é a mesma equipe que desenvolveu o sistema legado. Dessa forma, é necessária reengenharia dos processos envolvidos no software legado e uma integração do usuário/cliente na concepção do novo projeto.
6 Esta etapa foi fundamentada no trabalho realizado por Luciana Paiva e Victor Santander (Paiva e Santander 2004), sendo observada a relação da documentação do sistema legado com a sua reengenharia. Desta forma, as seguintes situações foram observadas: documentação inexistente: o sistema legado não possui nenhuma documentação. documentação desatualizada: situação comum tratando-se de sistemas legados, principalmente quando houve mudanças de membros de equipe de desenvolvimento. documentação atualizada: essa situação é a mais adequada, pois torna o processo ágil. Tem-se uma base de conhecimento consistente do sistema, facilitando a organização e captura dos requisitos. As situações da documentação do sistema legado com suas respectivas práticas para reengenharia dos processos do sistema legado podem ser visualizadas no quadro a seguir. Documentação Inexistente 1- Conhecer o funcionamento do sistema legado (E/S). 2- Analisar código fonte. 3- Entrevistar equipe / atores do sistema legado. 4- Documentar as informações levantadas. Práticas da Reengenharia Documentação Desatualizada 1- Conhecer o funcionamento do sistema legado (E/S). 2- Analisar código fonte. 3- Entrevistar equipe / atores do sistema legado. 4- Comparar a documentação existente com a análise efetuada, e atualizá-la. Documentação Atualizada 1- Conhecer o funcionamento do sistema legado (E/S). Quadro 1 - Resumo das práticas adotadas para a reengenharia do sistema legado. Para conhecer o funcionamento do sistema legado é necessário identificar principalmente os relatórios e consultas visuais. Independente da situação da documentação do sistema é importante que a equipe conheça o ambiente de aplicação, e que o analista tenha domínio com o negócio da organização. Esse conhecimento é necessário principalmente para análise dos riscos envolvidos nas mudanças de requisitos Planejamento Nesta etapa, é muito importante a realização de uma análise do histórico de projetos já realizados, caso exista. A seguir, são apresentadas as práticas e diretrizes que direcionam o planejamento. Seleção de Requisitos. Corresponde à definição dos requisitos do cliente que serão trabalhados no projeto. Esta seleção deve ser seguida pelas seguintes atividades:
7 a) Entender as informações levantadas: analisar os requisitos do sistema legado quanto ao grau de estabilidade, risco e influência nas atividades da organização, considerando as necessidades apontadas pelos stakeholders. b) Selecionar os requisitos funcionais: cabe ao cliente decidir quais os requisitos identificados serão mantidos, descartados ou melhorados, e definir novas funcionalidades para o sistema. c) Identificar os requisitos não funcionais: o cliente deve definir as restrições do sistema, suas necessidades de segurança, navegabilidade, dentre outros. Análise e Projeto. Nessa etapa é essencial adotar soluções simplificadas e eficientes. Para isso são apresentadas as seguintes diretrizes: a) Análise Orientada a Objetos: é indicado que seja realizada uma análise orientada a objetos, modelada em caso de uso. b) Projeto orientado a objetos: novos requisitos podem surgir neste momento, são os requisitos originados do projeto, que surgem a partir dos requisitos do cliente, para atender o desenvolvimento do projeto. c) Projeto Arquitetural: o projeto de arquitetura envolve a identificação dos principais componentes do sistema e das interconexões entre esses componentes. As decisões de um projeto de arquitetura têm um profundo efeito sobre a capacidade do sistema em implementar requisitos importantes como desempenho, confiabilidade e facilidade de manutenção. d) Projeto do banco de dados: essa estrutura será modificada também nos sprints, quando ocorre a revisão das classes e de seus atributos. A definição do projeto de banco de dados deve levar em consideração os dados do sistema legado que serão migrados. O banco precisa ser preparado para receber os dados do sistema legado. e) Projeto de Interface: a partir dos requisitos funcionais e não funcionais definidos pelos stakeholders, devem ser identificadas as necessidades de interface com o usuário e com outros softwares ou hardwares. Definição do Product Backlog. A partir dos elementos produzidos anteriormente, deve ser construído o Product BackLog. É importante destacar que o Product Backlog poderá ser modificado na etapa de desenvolvimento, para atender às mudanças de requisitos. As atividades identificadas como necessárias para o desenvolvimento do produto deve constar na lista, compondo o Product Backlog. Gestão do Conhecimento. É necessário que todo o conhecimento do projeto esteja bem organizado de forma a otimizar todo o processo de desenvolvimento, manutenção e comunicação da equipe. O gerenciamento do conhecimento pode ser conduzido seguindo os seguintes passos: a) Seleção do conhecimento: definição das informações que devem fazer parte da base de conhecimento. b) Definição dos itens de configuração: definição dos documentos, ou grupos de documentos relacionados, que estarão sob o controle de configuração.
8 Os itens de configuração a serem gerenciados devem ser escolhidos com base no planejamento das mudanças do software. c) Controle de versão: definição dos procedimentos e ferramentas para gerenciar as diferentes versões dos itens de configuração. d) Padrão de Codificação: devem ser estabelecidos padrões de codificação para serem seguidos durante o desenvolvimento e auxiliar a comunicação através do código. e) Construção da Matriz de Rastreabilidade: através de uma matriz de rastreabilidade é possível relacionar os requisitos com as funcionalidades implementadas, ajudando na manutenção da consistência do software num possível momento de manutenção do sistema. f) Controle das mudanças dos requisitos: todas as alterações realizadas em um requisito devem ser registradas. g) Definição dos sistemas e ferramentas de compartilhamento de conhecimento: o conhecimento deve ser mantido em um depósito de dados seguro e gerenciado, que seja acessível por todos os envolvidos no processo de Engenharia de Software. Seleção de Tecnologia e Ferramentas. É necessário avaliar adequadamente o risco das novas tecnologias e ferramentas CASE (Computer-Aided Software Engineering). a) Avaliação e escolha da tecnologia: as tecnologias devem atender às exigências do sistema (arquitetura, desempenho, segurança, portabilidade, entre outras), serem orientadas a objeto, além disso, devem atender a critérios como área de aplicação geral, complexidade computacional e algorítmica, disponibilidade de profissionais capacitados, acesso à documentação. b) Avaliação e escolha das ferramentas CASE: as ferramentas CASE auxiliam atividades de Engenharia de Software, como gerenciamento de requisitos, análise, modelagem, programação, refatoração de código e testes. Os fatores que devem ser avaliados ao escolher as ferramentas são: complexidade, experiência da equipe, custo e integração entre ferramentas. Estimativa de Esforço e Custo. Correspondem à estimativa de desenvolvimento e à estimativa de atividades de apoio (treinamento dos recursos humanos, aquisição de ferramentas de apoio, análise de projeto, entre outros). As estimativas de custo e tempo na prática não são exatas. Mas é necessária uma estimativa inicial que dê rumo ao projeto e influencie nas decisões a serem seguidas. Contudo, os recursos e escopo do projeto devem ser reanalisados periodicamente, em cada sprint. Seleção e Capacitação da Equipe. Corresponde à seleção de recursos humanos, definição de responsabilidades e treinamento Desenvolvimento
9 A fase de desenvolvimento, ou implementação, foi baseada nas práticas da Scrum, é constituída de ciclos iterativos, sprints, que implementam um conjunto de itens de Product Backlog. As práticas que devem ser realizadas em cada sprint são: Planejamento do release. Consiste em uma reunião entre cliente e gerência do projeto, onde o cronograma, os componentes, os módulos prioritários, as medidas de desempenho e quantos itens do backlog podem ser feitos em cada iteração são definidos. Planejamento do sprint. Prática realizada no início de cada sprint. Corresponde a um plano do novo sprint definido a partir das prioridades do cliente e estimativas técnicas. O planejamento deve seguir as seguintes diretrizes: a) Construção do Sprint Backlog: a seleção dos itens do backlog que serão desenvolvidos, constituindo o Sprint Backlog, é definida pelo cliente, baseado na sua prioridade. A gerência de projeto deverá verificar a matriz de rastreabilidade para analisar as dependências entre os requisitos e a relação com componentes, definindo a viabilidade do desenvolvimento desses itens selecionados. b) Definição do teste de aplicação: o cliente deve descrever os testes de aplicação para cada final de ciclo, conduzindo o desenvolvimento e estabelecendo um critério de validação. c) Alocação de recursos: a equipe responsável pelo desenvolvimento do Sprint Backlog é formada. O esforço necessário e a experiência com o sub-ambiente de aplicação a ser trabalhado são critérios a serem analisados para definir o tamanho e membros da equipe, respectivamente. As equipes podem ser formadas para atuarem em um determinado conjunto de funcionalidades ou em determinadas camadas do sistema. d) Projeto do sprint: o gerente do projeto, com o auxílio da equipe de desenvolvimento, projeta detalhadamente o sprint. e) Cronograma: cada atividade do sprint deve ser definida, com prazos e responsáveis, obedecendo o tempo ideal estabelecido para cada iteração. Desenvolvimento do sprint. a) Testes: os desenvolvedores, com base no teste de aplicação definido pelo cliente e com uma análise dos itens a serem implementados, escrevem testes de unidade mais detalhados, para validar o sprint. É implementado um teste para cada item do backlog, antes mesmo de ocorrer a implementação. b) Reuniões diárias: todo dia, ou em dias alternados, é realizada uma reunião com uma duração média de 15 minutos onde a equipe expõe à gerência as atividades a serem feitas até próximo encontro, os fatores de impedimento, e o progresso geral do desenvolvimento. Nessa reunião será criado um documento, que indique as inconsistências entre o projeto de trabalho e os requisitos alocados.
10 c) Refatoração: a cada nova funcionalidade desenvolvida, o design do código deve ser trabalhado até ficar na sua forma mais simples, eliminando duplicações e melhorando a comunicação e flexibilidade. Esta melhoria é feita sem comprometer o comportamento externo do software. d) Revisão de padrão: a partir da definição dos padrões de codificação determinado na etapa de planejamento, o desenvolvedor deverá analisar se o seu código segue as exigências do projeto, realizando as devidas modificações. As atividades de refatoração, testes de unidade e padronização do código são baseadas na XP. Enquanto a reunião diária, com feedback constante, é uma prática ágil comum a XP e Scrum. Reunião de revisão do sprint. A reunião de revisão ocorre no último dia do sprint. A equipe de desenvolvimento, o cliente e o gerente de projeto devem estar presentes nesta reunião. a) Análise dos resultados: análise dos relatórios das reuniões diárias, verificando as inconsistências encontradas entre os requisitos alocados e o que foi desenvolvido. b) Análise de riscos: o gerente deve discutir com a equipe e o cliente as possibilidades de riscos ao final de cada sprint. Quando o risco tem origem ou impactos funcionais, ou seja, diretamente ligados à gerência de requisitos, a matriz de rastreabilidade deve ser utilizada para orientar essa análise. c) Atualização do Product Backlog: novos itens de backlog, que se apresentarem necessários durante a reunião, podem ser adicionados na lista de backlog. d) Atualização da documentação: nas reuniões de revisão são documentadas todas as discussões e soluções relevantes para as etapas futuras e para o histórico da organização, de forma a facilitar a comparação com outros projetos Pós-desenvolvimento O pós-desenvolvimento consiste nas etapas de Encerramento e Substituição Encerramento Ao final de um conjunto de sprints, quando a gerência percebe que tem uma versão estável com as novas funcionalidades requeridas, com qualidade e pronta para competir, essa nova versão é declarada encerrada e o processo entra em no estágio de encerramento. Portanto, após a verificação do cliente, tem-se um release que já pode entrar em operação. As práticas do encerramento são descritas a seguir. Testes de sistemas: correspondem a testes realizados para verificação das funcionalidades do sistema. Inclusive comparando o sistema legado com sistema novo, através de uma simulação dos processos do sistema legado que foram incorporados no sistema novo.
11 Testes de integração: no final de cada sprint a integração dos itens desenvolvidos com o software deve ser testada. Testes de estresse: após a integração completa do sistema é possível testá-lo quanto aos requisitos não-funcionais como desempenho, portabilidade e confiabilidade. Criação de documentação do usuário: nessa fase deve ser criado o manual do usuário. Sempre que possível deve ser utilizado sistema de ajuda on-line. Se, por ventura, os casos de testes não forem satisfatórios, deve-se retornar ao estágio de desenvolvimento, incluindo os novos itens no Product Backlog. Contudo, esse caso é uma exceção, já que testes devem ser realizados periodicamente, ao final de cada sprint. Considera-se que o encerramento só é alcançado quando realmente se tem certeza que a versão é estável Substituição O estágio de substituição ocorre quando o cliente confirma a validação e verificação do sistema, não havendo mais nenhuma pendência para que o novo sistema entre em operação. Para realizar a substituição do sistema novo pelo sistema legado é fundamental a adoção das práticas abaixo: Treinamento. A equipe responsável pelo treinamento deve conhecer o sistema legado, identificar a relação de cada processo da empresa executado nos dois sistemas, atentando-se principalmente para as funcionalidades que se comportam de maneira diferente entre o novo e antigo sistema. Além disso, o marketing interno do software desenvolvido é importante para mostrar aos usuários as vantagens do processo de substituição. Migração dos dados. Os dados do sistema legado que serão migrados, já definidos na etapa de planejamento, serão mapeados no novo sistema, e posteriormente deverá ser preparado um programa (rotina) para sua migração automática, é aconselhável executar simulações numa área de testes, para evitar surpresas desagradáveis. Homologação. Quando o novo sistema estiver implantado, o cliente deverá assinar um termo de homologação, registrando a finalização do processo de substituição do sistema legado. Depois de realizada a substituição do sistema legado, essa Estratégia poderá ser utilizada para as futuras manutenções, já que foi estruturada para prever essa evolução. Contudo, nos casos de manutenção, os estágios de reengenharia e substituição devem ser descartados. Além disso, devem ser descartadas também as atividades restritas para o caso de substituição, ou seja, não são utilizadas em processos de desenvolvimento e manutenção de software, por exemplo, a definição dos dados a serem migrados (estágio de planejamento), e a simulação do sistema novo no sistema legado (estágio de encerramento). No Quadro 2 é possível visualizar a Estratégia resumida nas fases, estágios e práticas adotadas.
12 Reengenharia Estratégia para substituição de sistema legado Pré-desenvolvimento Conhecer o funcionamento do sistema legado (E/S) Analisar código fonte. Entrevistar equipe / atores do sistema legado. Planejamento Análise Definição do Product Backlog Gerenciamento do Conhecimento Seleção da Tecnologia e Ferramentas CASE Estimativa de Esforço e Custo Seleção e Capacitação da Equipe Planejamento do release Planejamento do sprint Desenvolvimento do sprint Reunião de revisão do sprint Encerramento Testes de sistemas Testes de Integração Testes de Estresse Criação de documentação do usuário Substituição Treinamento Migração de dados Homologação 5. Considerações Finais Desenvolvimento Pós-Desenvolvimento Quadro 2 - Resumo da estratégia de substituição de sistema legado. A substituição de sistema legado é uma solução arriscada e por vezes radical, mas a depender da situação pode ser a melhor opção a ser adotada para os negócios da organização. Contudo, é necessário que as empresas de desenvolvimento de software tratem a substituição de sistemas legados como um processo diferenciado de produção, considerando as suas peculiaridades. É notado que as metodologias normalmente utilizadas para desenvolvimento de software não são adequadas a ambientes de desenvolvimento de software caracterizados pela instabilidade e imprevisibilidade dos requisitos, risco associado à alta influência nos processos da organização, além da necessidade de um curto tempo de resposta. Portanto, a Estratégia apresentada se mostra relevante ao orientar o processo de desenvolvimento de software através de soluções que minimizam os impactos causados
13 pela substituição de sistemas legados. É proposta a utilização de práticas ágeis, que lidam com processos mais simples, mais eficientes e que atendem às mudanças de requisitos e auxiliam no levantamento das necessidades do cliente. A fidelidade do software às necessidades da empresa é ampliada através da reengenharia das funcionalidades do sistema legado e de constantes interações com os stakeholders,. Suas práticas voltadas para o controle contínuo do conhecimento e mudanças são essenciais para atender ao caráter evolutivo desse tipo de software. As reuniões periódicas facilitam a boa comunicação da equipe com o cliente. A preocupação com o aumento do tempo de vida útil e com a minimização de reincidências dos problemas encontrados no sistema legado faz valer os investimentos da organização pela substituição do software legado. É importante destacar que a eficiência desta Estratégia depende muito mais das pessoas que dos processos. A construção do software útil depende do conhecimento da equipe de desenvolvimento quanto aos processos envolvidos na aplicação, da sua coragem para aceitar mudanças, da sua relação com o cliente e da percepção da necessidade dos processos. Além disso, é necessário perceber que uma transformação de paradigma só eficiente se for compreendida e aceita por todos os atores envolvidos. Referências Adolph, W.S. (1996) Cash Cow in the Tar Pit: Reengineering a Legacy System. In: IEEE Software, v. 13, n. 3, p Beck, K. (2000) Extreme Programming Explained: Embrace Change. Addison Wesley. Bisbal, J. et al. (1999) Legacy information systems: issues and directions. In: IEEE Software, v. 16, n. 5, p Manifest for Agile Software Development (2001). <http://agilemanifesto.org>. Paiva, L.; Santander, V. (2004) Uma proposta de evolução em Sistemas Legados, In: Anais do WER04 - Workshop em Engenharia de Requisitos, Tandil, Argentina, p Schwaber, K. (1995) SCRUM Development Process, In: OOPSLA'95 Workshop on Business Object Design and Implementation, 1995, Springer-Verlag. Anais eletrônico. <http://www.jeffsutherland.org/oopsla/schwapub.pdf >. Soares, M. (2004) Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. In: Revista Eletrônica de Sistemas de Informação, Ed. 4. <http://www.presidentekennedy.br/resi/ >. Sommerville, I. (2003) Engenharia de Software. 6ª. ed.: Addison Wesley Professional. Wuestefeld, K. (2001) XisPê Extreming Programming. <http://www.xispe.com.br/>.