Este documento resume um trabalho sobre rejuvenescimento de software gerido pelo Project Office. Ele explica o que é rejuvenescimento de software e suas características, apresenta uma metodologia proposta e um estudo de caso onde o rejuvenescimento e o Project Office foram aplicados.

1. Rejuvenescimento de Software gerido pelo Project Office
Bruno Lins Alves, Diego Calasans, Eduardo Dória Lima, Marcus Vinicius de Gois Oliveira
Universidade Federal de Sergipe
Cidade Universitária Prof. José Aloísio de Campos
Av. Marechal Rondon S.N.
São Cristóvão-SE
CEP: 49.100-000
brunolinsalves, d.calasans, doriaeduardo, mvgois{@gmail.com}
Abstract presença de modularizações. São boas práticas que
In this paper, there is an explanation of what is the ajudam na manutenção do código e favorecem a
practice of software rejuvenation. They both said all its aplicação do rejuvenescimento de software.
features and subdivisions, and technologies that serve to Logo, tem-se que rejuvenescimento de software é um
help it. Additionally, there is an introduction about the conjunto de técnicas que facilitam a manutenabilidade e
Project Office. Then, it demonstrated a way to make the conseqüentemente a adaptação à novas tecnologias pela
analysis of a system. Thus, there is need or not of maioria dos softwares, se vê nas próximas seções que
rejuvenation. It was also proposed as an example, a case nem todos os softwares são adeptos a essa técnica.
study that after made its analysis, the appropriate
Verifica-se ainda na seção 1.1, alguns dos trabalhos
conclusions were drawn. Finally it was explained how to relacionados ao tema que serviram como fonte de
use the Project Office in the case study proposed. How
pesquisa para elaboração desse trabalho.
does it affect the organization as well as have studied the
importance of implementation of rejuvenation. Na seção 2, descreve-se o que significa cada técnica,
onde é utilizada e algumas tecnologias que utilizam a
Categories and Subject Descriptors técnica do Rejuvenescimento, incluindo Project Office.
D.2.10 [Software]: Software Engineering: Design – Na seção 3, é mostrada uma maneira de se fazer a análise
Methodologies. de um sistema para que se verifique a necessidade ou não
do rejuvenescimento e, é trazido um estudo de caso local
General Terms onde é aplicado o rejuvenescimento e o Project Office.
Design
Na seção 4, são expostas as considerações finais e por
Keywords fim, na seção 5, as referências utilizadas.
Software, rejuvenation, methodology, Project Office
1.1Trabalhos Relacionados
Nesta seção serão abordados os principais artigos
Resumo referentes ao tema Rejuvenescimento que foram
Neste trabalho, encontra-se uma explicação sobre o que estudados, os quais serviram de base para elaboração
se trata a prática de rejuvenescimento de software. São deste trabalho.
citadas tanto suas características e subdivisões, como
também tecnologias que servem de auxilio a ela. 1.1.1Yennun Huang
Adicionalmente, é feita uma introdução sobre o Project O artigo [8] foi o primeiro a aplicar o termo “software
Office. Em seguida, é demonstrada uma maneira de fazer rejuvenation”. Nele é proposto um modelo de análise de
a análise de um sistema. Dessa forma, se verifica a sistemas que analisa o impacto do rejuvenescimento de
necessidade ou não do rejuvenescimento. Foi proposto determinado sistema para a organização.
também, como exemplo, um estudo de caso onde depois Segundo ele, o envelhecimento de sistemas é um
de feita a sua análise, foram tiradas as conclusões processo de duas etapas. Do estado estável, o sistema
adequadas. Para finalizar foi explicado como usar o entra em um estado de possível falha. A partir daí duas
Project Office no estudo de caso proposto. De que ações são possíveis: ou entrar em um estado de
maneira ele afetará a organização estudada e também rejuvenescimento, ou entrar em um estado de queda
como teria importância na aplicação de práticas de completa. Esse modelo é criticado por ser um modelo
rejuvenescimento. baseado em caixa-preta e por não levar muito em conta a
performance do sistema.
Palavras-chave
Software, rejuvenescimento, metodologia, Project Office
1.1.2Sachin Garg
Em [10] é defendida a idéia de usar um intervalo de
1.INTRODUÇÃO rejuvenescimento periódico e fixo, não levando em conta
Segundo [2], para melhorar o processo de o estado do sistema proposto por [8] durante esses
desenvolvimento de software, atualmente, a tendência é rejuvenescimentos. Trabalha usando redes de Petri para
fazer reaproveitamento de código. Reusabilidade é um analisar o comportamento do software.
conceito que ganha cada vez mais espaço. Para isso
precisa ter um software bem estruturado, que obedeça
alguns padrões, uma arquitetura bem definida e a

2. 1.1.3Andrea Bobbio O artigo [2] afirma que a linguagem mais adequada é a
O artigo [9] fala que é possível identificar a perfomance orientada a objetos. Por isso a necessidade de se aplicar o
do sistema de acordo com observações e que o processo rejuvenescimento a estes tipos de sistemas.
de degradação vem de uma seqüência sucessiva de falhas O rejuvenescimento surge também da necessidade de se
e quebras. incluir novas funcionalidades em um sistema em que não
Existe também um parâmetro de observação que é o que é simples tal inclusão.
vai decidir se um sistema entrou ou não em um estado de De acordo com [1], há diversas estratégias para tal:
queda.
i. Redocumentação
1.1.4Nuno Alberto Pereira da Silva ii. ReestruturaçãoRefatoração
Em [2], o autor aborda as necessidades dos softwares de
iii. Engenharia reversa
se adaptarem às constantes mudanças nas empresas, as
vantagens de não precisar refazer um software do início, iv. Reengenharia
descrevendo como fazer o rejuvenescimento de um
sistema legado ou crítico. Toma como estudo de caso os 2.2Redocumentação
sistemas financeiros, em particular, das empresas de Efetuar uma análise do código, de forma a produzir
seguros. documentação explicativa do código.
Segundo [13], redocumentação é uma técnica muito
1.1.5Eliete Marchioro importante quando se pensa em melhorar o custo de
Em [6], a autora estuda causas e técnicas para superar o manutenção do software, pois segundo o mesmo, devido
envelhecimento de software relacionado aos servidores a alta rotatividade de profissionais, tudo deve ser
Web Apache. documentado para evitar que apenas uma pessoa entenda
A mesma apresenta técnicas de rejuvenescimento e detalhadamente o sistema.
explica como ocorre o envelhecimento, realizando dessa O autor afirma ainda que a redocumentação tem como
forma um estudo de caso e descrevendo os resultados características básicas:
obtidos.
i. Ser baseado na engenharia reversa – A partir do
2.CONCEITOS E TECNOLOGIAS código obtido na engenharia reversa, construir a
Nesta seção pretende-se esclarecer do que trata cada documentação;
técnica utilizada para a elaboração deste trabalho, assim ii. Gerar documentação mínima necessária – Não se
como, apresentar algumas tecnologias que utilizam a deve levar muito tempo para elaborar a
metodologia proposta. documentação, deve-se ser o mais objetivo
É descrito o Project Office e as técnicas utilizadas no possível;
rejuvenescimento em detalhes, conforme Figura 1. iii. Buscar automatização quando possível – Deve-se
utilizar de ferramentas que auxiliam na
documentação de softwares a fim de agilizar o
processo.
2.3ReestruturaçãoRefatoração
Efetuar uma análise do código, de forma a reestruturar-lo
para uma estrutura mais eficiente.
Em [15], temos que a refatoração tem como objetivo de
modificar um sistema de software para melhorar a
estrutura interna do código sem alterar o seu
comportamento externo.
Com isso, pretende-se melhorar o entendimento do
código. Existem também diversas ferramentas que
servem e são úteis para automatizar esse processo.
Figura1 - Relacionamentos no Ciclo de Desenvolvimento
de Software (CHIKOFSKY e CROSS, 1990)
2.4Engenharia Reversa
Efetuar uma análise do código, de forma a gerar o
2.1Rejuvenescimento de Software modelo e especificações que lhe deram origem.
Segundo [1], o rejuvenescimento de software tem a Em [14], temos que engenharia reversa é processo
finalidade de melhorar a qualidade do software reduzindo inverso da engenharia de software. Com esta técnica
os custos com sua manutenção. Em [2], o autor afirma podemos, a partir de um produto, obter o código-fonte
que os sistemas mais indicados para se utilizar essa que lhe deu origem.
metodologia são os sistemas críticos e sistemas legados,
pois são sistemas com confiabilidade muito alta e que O autor de [14] cita alguns exemplos de uso desta
geralmente utilizam linguagens procedimentais que, pela técnica, tais como: cracks, pessoas conseguem quebrar a
sua natureza, não suportam alguns princípios tidos como segurança dos softwares a fim de obter licenças de
necessários para uma fácil evolutibilidade dos sistemas, utilização dos mesmos; Samba, software do sistema
tais como: Linux que se utilizou desta técnica para conseguir fazer a
comunicação entre o Linux e o sistema Windows.
i. Grau de reutilização do código
ii. Não duplicação do código
iii. Testabilidade do código

3. 2.5Reengenharia A fase de “Escrita de testes” deverá ser realizada antes do
Segundo [12], partindo-se do sistema existente (via inicio da codificação da nova funcionalidade. Nessa fase,
código-fonte, interface ou ambiente), são abstraídas as devem ser criados os casos de teste, para descrever o
suas funcionalidades e é construído o modelo de análise e funcionamento esperado por essa nova funcionalidade.
o projeto do software. Os programadores do sistema usarão esses casos de teste
para entender melhor os objetivos dessa funcionalidade.
Caso não se tenha dados suficientes para se fazer a
reengenharia, pode-se utilizar a engenharia reversa, e Depois que os casos de teste já foram criados, devemos
então gerar novo modelo e novo código para auxiliar no começar a fase de “Codificação” do sistema. Essa fase irá
processo. codificar a nova funcionalidade utilizando uma
linguagem de programação. O programador deve-se
2.6Metodologia Proposta atentar que o uso de padrões para codificação além de
Nesta seção será apresentada uma metodologia de melhorar a legibilidade do código, ele propõe soluções
desenvolvimento que pode ser utilizada para o para alguns problemas comuns da codificação, como o
rejuvenescimento de software. acesso à dados. A “Refatoração”, pode ser consideração
uma sub-fase da “Codificação”, visto que seu objetivo é
A metodologia proposta a seguir é baseada nos conceitos
melhorar a estrutura do código.
das metodologias ágeis, sendo assim, ela utiliza ciclos
rápidos de iteração com pequenas alterações em cada Uma das fases mais importantes do ciclo de
ciclo. Todos os releases do software deverão ser desenvolvimento de software é a “Execução de Testes”.
validados através da execução de testes no mesmo. Sendo Pois é ela que garante que o sistema continua a funcionar
assim, antes de começar a codificar uma nova de acordo com a sua lista de requisitos. Nessa
funcionalidade do sistema, é necessário planejar os casos metodologia, a “Execução de Testes” assume uma
de teste para testar todas as possibilidades de execução, importância ainda maior, pois como a refatoração é muito
inclusive as situações de erros. utilizada, surge a necessidade da execução de testes que
validem todo o sistema.
Segundo [12], partindo-se do sistema existente (via
código-fonte, interface ou ambiente), são abstraídas as O ciclo de desenvolvimento se encerra com o “Produto”.
suas funcionalidades e são construídos o modelo de Nessa fase, será liberada uma nova versão do software
análise e o projeto do software. que será chamada de produto. Os produtos não devem
acumular um grande volume de alterações, devido à
A metodologia proposta é composta por sete fases,
representada pela Figura 2. facilidade de dar um rollback sempre que ocorra alguma
coisa errada.
2.7Project Office
Nos modelos tradicionais de gerencia de projetos, um
gerente ficaria encarregado por todos ou apenas alguns
projetos da empresa. Porém essa abordagem possui
desvantagens que podem levar ao fracasso do projeto:
i. O gerente de projeto fica sobrecarregado com as
tarefas administrativas associadas ao
gerenciamento do projeto;
ii. A falta de padrões dificulta o controle e
acompanhamento do projeto;
iii. Não existe um banco de dados de lições
aprendidas em projetos anteriores.
Figura 2 – Metodologia Proposta Devido ao desejo de melhorar a taxa de sucesso dos
A primeira fase, chamada de “Nova Funcionalidade”, projetos, as empresas estão adotando um novo modelo de
inicia-se quando o cliente identifica a necessidade de gestão de projetos: o Project Office.
criar, ou alterar uma funcionalidade já implementada pelo O Project Office, ou Escritório de Projetos, é uma área da
sistema. empresa que tem uma visão de todos os projetos da
Após a identificação de uma nova funcionalidade, é mesma. Dentro desse escritório de projetos, serão
necessário identificar os requisitos dessa nova debatidas questões para melhorar o planejamento e
funcionalidade. Essa é a principal tarefa da fase de condução dos projetos. O escritório também fornecerá
“Recolher histórias dos clientes”. Para a identificação informações rápidas sobre a situação dos projetos,
desses requisitos, podem ser usadas reuniões com o auxiliando a tomada de decisões
cliente e a equipe de desenvolvimento, com o objetivo de Segundo o Gartner[3], existem cinco atividades
criar uma lista com todos os requisitos envolvidos na desempenhadas pelo Project Office, que contribuem
implementação dessa nova funcionalidade. bastante na gerencia de projetos. São elas:
O objetivo da fase de “Desenho”, ou “Projeto”, é i. Padronização de uma Metodologia – Define uma
representar a nova funcionalidade através de elementos ferramenta e métodos de controle e
visuais, chamados de modelo. Para isso, pode-se usar acompanhamento de projetos;
linguagens visuais de modelagem como a UML (Unified
Modeling Language). Esses modelos deverão ser usados ii. Avaliação dos recursos de projetos – Todos os
para analisar os impactos que o desenvolvimento dessa recursos dos projetos são analisados para a
nova funcionalidade pode trazer ao sistema. análise do desempenho e prioridade dos projetos;

4. iii. Planejamento de Projetos – O planejamento é O processo de rejuvenescimento através do Metex é
centralizado e coordenado. Devem-se utilizar as dividido em quatro fases:
lições aprendidas nos projetos anteriores; i. Revisão de arquitetura – Discussão com o cliente
iv. Gerenciamento de Projetos - Defini as melhores sobre a nova arquitetura;
práticas de trabalho com o intuito de facilitar o ii. Conversão automática de código – A ferramenta
gerenciamento; converte o código automaticamente dentre os
v. Revisão e Análise de Projetos – Constante aceitos por ela;
revisão das atividades, custo e prazos e impactos iii. Utilização de ferramentas avançadas para
nos projetos. completar o código – Após a conversão pode
Para combinar os conceitos de Project Office com o ocorrer de algum código não ter sido convertido,
rejuvenescimento de software, seria necessário, nesse caso são utilizadas algumas ferramentas
primeiramente, que a empresa adotasse o conceito de avançadas do Metex para completar a conversão;
Project Office, criando uma área que possuísse uma visão iv. Teste de integração e Verificação – O Metex
de todos os projetos da empresa e desempenhasse as também oferece ferramentas para verificação e
cinco atividades citadas anteriormente. O segundo passo testes do código gerado;
seria utilizar o rejuvenescimento de software como parte
da metodologia de desenvolvimento na empresa. v. Teste de aceitação de usuário – Ao final do
processo é utilizado um rastreador de bugs online
2.8Tecnologias e Ferramentas para correção de possíveis erros.
Nesta seção serão apresentadas algumas ferramentas
A Figura 3 representa a arquitetura-base para uma
tecnológicas que utilizadas no rejuvenescimento de
aplicação Web (arquitetura em três camadas):
software automatizam e, conseqüentemente, agilizam o
processo. A camada mais alta é a camada de interface, representada
na figura pela coluna mais à esquerda na imagem. Em
2.8.1LegayJ seguida, temos a camada de lógica de negócio,
A ferramenta LegacyJ tem como característica a pouca ou representada na figura pela coluna central. E por último
nenhuma modificação no código. O software apenas existe a camada de acesso a dados, representada na figura
permite a integração de aplicações escritas em COBOL pela coluna mais à direita.
com tecnologias baseadas em J2EE. EJB é um exemplo Como citado anteriormente, essa arquitetura é a base para
das tecnologias suportadas. uma aplicação Web, nada impede que a arquitetura
O LegacyJ permite ainda, a edição de código fonte possua mais do que três camadas. Com o Metex, a
COBOL na IDE (Integrated development environment) arquitetura cliente/servidor pode ser atualizada para uma
Eclipse. arquitetura em N-camadas sem restrições.
2.8.2Micro Focus Net Express
O Micro Focus Net Express é uma ferramenta auxiliar na
prática do rejuvenescimento e serve para tornar
aplicações COBOL em aplicações Web.
O Net Express também torna aplicações COBOL
compatível com servidores JAVA. Além de permitir o
compartilhamento de dados entre aplicações através do
uso de XML.
2.8.3Metex
O Metex é um software que tem como principal objetivo
recriar aplicações legadas, entregando um código de
altíssima qualidade. Figura 3 – Arquitetura em três camadas
Tal ferramenta possui a capacidade de transformar o Na Figura 4 temos a representação do processo de
código fonte escrito em PowerBuilder, Oracle Forms, rejuvenescimento aplicado pelo Metex e aqui descrito.
Forte, VB ou Centura em um código JAVA ou .NET.
Segundo os criadores do programa, o que classifica o
Metex como uma ferramenta de rejuvenescimento de
software e não apenas como um migrador de código é o
fato de que o Metex transforma aplicações legadas
cliente/servidor em aplicações com arquiteturas
modernas, escolhida pelo usuário, em JAVA ou .NET.
A ferramenta apresenta ainda alguns serviços adicionais
tais quais:
i. Transformação;
Figura 4 – Processo de rejuvenescimento no Metex
ii. Reengenharia;
A Figura 5 mostra um comparativo do rejuvenescimento
iii. Documentação UML; de software aplicado manualmente (linha vermelha)
iv. Migração de Banco de dados; versus rejuvenescimento aplicado com Metex (linha
verde) versus uma simples tradução de código (linha
v. Habilitação para Web. azul).

5. Muitas dessas causas, como se pode notar, são quase que
completamente amenizadas hoje em dia, devido às
linguagens de alto nível e as plataformas de
desenvolvimento modernas. Um software bem feito,
usando ferramentas modernas e adequadas tem sua curva
de degradação muito mais longa que um software legado
teve, por exemplo. Apesar de esse fato existir, o software
nunca deixará de envelhecer, por menor que seja, o
rejuvenescimento constante é recomendado na imensa
maioria dos sistemas, como veremos abaixo.
Às vezes se tem a duvida sobre porque é tão importante o
rejuvenescimento. A resposta é que um sistema com o
passar do tempo, como já foi dito, vai envelhecendo e
Figura 5 – Comparação das formas de esse envelhecimento pode chegar a tal ponto de deixar-lo
rejuvenescimento inativo, ou melhor, causando sua queda. Dessa forma,
todos os seus serviços ficarão fora de disponibilidade.
Como pode ver na Figura 5, o rejuvenescimento feito
manualmente apresenta o maior custo durante um tempo O problema é que nenhum sistema vai ficar sempre ativo
maior na fase de tradução de código (linha sólida), durante toda sua vida útil, pois não existem sistemas
porém, o custo da manutenção cai significativamente. totalmente perfeitos. Por mínima que seja, uma hora a
manutenção deve ser feita, portanto, é importante para a
Já a migração de código feita através de tradutores se organização saber quando o sistema está perto de entrar
mostra menos custosa na fase de tradução, porém o custo em um estado de queda ou não a fim que se evite esse
da manutenção sobe drasticamente. estado de queda. Evitando que sua queda fará com que a
Apesar de o custo da fase inicial, utilizando o software organização não arque com os prejuízos dessa perda, que
Metex, ser superior ao custo inicial utilizando um com certeza, na imensa maioria dos casos, são bem
tradutor, o custo da manutenção da aplicação é muito maiores do que o custo de uma queda programada,
inferior, o que acaba por justificar o uso do Metex. necessária para fazer a manutenção. Podemos notar a
partir disso, que o aumento do tempo de vida da
3.ANÁLISE DE APLICAÇÕES aplicação, junto com o seu monitoramento, a fim de
O rejuvenescimento de software é um pratica interessante evitar quedas não planejadas, traz muita economia para
para se propor a uma organização desenvolvedora de organização.
sistemas, pois os sistemas degradam ao passar do tempo e
a pratica de rejuvenescimento faz com que a sua vida útil 3.1Diferentes Abordagens
seja prolongada o máximo de tempo possível. Existem duas diferentes abordagens a serem aplicadas
nos sistemas a fim de aumentar sua vida util. A primeira é
Todo software sofre um processo de envelhecimento, que a prevenção reativa, que é a mais comum. Nela toda
na verdade se trata da degradação gradual da sua decisão é tomada somente quando ocorre algo errado no
performance. Ao longo do tempo, esse processo de sistema. Assim que a aplicação entra em um estado de
envelhecimento pode deixar esse software em um estado inutilidade, queda ou perto disso, é tomada uma decisão,
de inutilidade, tirando assim a necessidade dele. que pode ser desde rollbacks, até reiniciar o sistema,
Segundo [8] e [9], existem várias causas que podem ordenar arquivos, ou alguma manutenção mais seria nas
provocar e agravar esse processo de envelhecimento, funcionalidades. A segunda abordagem é a prevenção
algumas delas são: proativa e preventiva, que como o próprio nome já diz,
nela não espera que aconteça algo para tomar uma
i. Vazamento de memória – Quando um sistema faz
decisão. A cada momento, a situação atual do sistema é
uso da memória, mas não verifica o “lixo” que
visualizada para que se tome uma decisão adequada de
deixa nela após o uso. Isso vem sendo mais
acordo com a necessidade, evitando que o sistema entre
atenuado com as linguagens de alto nível, tipo
em um estado de queda. É nesse tipo de prevenção que
Java, que possui na sua maquina virtual um
faz parte o rejuvenescimento de software.
Garbage Collection que faz o gerenciamento da
memória; 3.2Estados do Sistema
ii. Uso progressivo de discos de armazenamento – Quando um sistema está com todas suas funcionalidades
Esse é um problema já praticamente inexistente ao máximo, atendendo completamente às necessidades e
hoje em dia, devido o barateamento das unidades sem riscos de quedas, ele se encontra em um estado
de armazenamento, mas já foi um ponto crítico estável. Mas nem sempre esse estado permanece, causas
dos sistemas, que ocupavam espaço adversas já ditas anteriormente fazem com que o software
continuamente com logs ou caches por exemplo; entre em um estado de provável falha. Nesse ponto ele
ainda está funcionando, mas se consegue notar que algo,
iii. Uso de estruturas e arquivos desatualizados –
por mínimo que seja, está errado. Esse erro que pode ser
Quando um sistema usa bibliotecas que estão
tanto provocado pela implementação do próprio sistema
desatualizadas ou arquivos que não existem mais
em si, como do ambiente em que ele está envolvido.
suporte para manutenção, por exempl;.
A partir do estado de provável falha, caso nada seja feito,
iv. Erros de arredondamento numérico em excesso –
só existe um caminho a seguir: que é o caminho da
São erros que aparentam ser simples, mas simples
queda. Agora o sistema já está indisponível, não existe
erros de cálculos podem levar a aplicação a um
mais nada a fazer que não seja parar tudo e fazer a
estado de falha.
manutenção, voltando a um estado estável novamente e
iniciando o ciclo.

6. rejuvenescimento. Mas como o custo de uma queda
planejada é muito menor que o custo de uma queda não
planejada, então for definido como maior importância o
custo e não o downtime, na grande maioria das vezes o
rejuvenescimento freqüente vai ser adequado.
3.3Estudo de Caso
Nesse trabalho, foi analisado como estudo de caso o
Figura 6 – Software sem o rejuvenescimento Aplicativo CPD/RH, usado na Prefeitura Municipal de
Aracaju e o setor de TIC como um todo. Esse sistema é
De acordo com a Figura 6 pode-se ver o ciclo completo usado para gerar a folha de pagamento dos funcionários e
do sistema sem o uso do rejuvenescimento, onde λ é a outras funcionalidades gerais da administração como:
taxa de queda de um sistema. férias, décimo terceiro salário, adicionais, pensões,
Quando um sistema entra em um estado de provável contra-cheques, relatórios e várias outras.
falha, outro caminho pode ser feito. É ai que entra o
rejuvenescimento. Pela Figura 7 pode-se ver a nova
abordagem. Dessa vez um novo estado é criado, que é
chamado estado de rejuvenescimento. É importante
observar que tanto o estado de rejuvenescimento, quanto
o estado de queda, o sistema estará fora de serviço. Mas a
grande diferença é que no estado de rejuvenescimento, o
sistema estará fora de uma maneira planejada.
Figura 8 – Tela do sistema Aplicativo CPD/RH
Ele foi feito por uma empresa terceirizada e desenvolvido
em Visual Basic a partir de um contrato específico, onde
teria garantia da manutenção do mesmo durante um
período de 24 meses, fora os demais termos da Garantia
Legal Tecnológica.
Figura 7 – Software com o rejuvenescimento
Existe também uma versão Web do mesmo sistema,
O objetivo é tentar deixar o sistema no estado estável o chamado FolhaNET, onde acessa a mesma base de dados
maior tempo possível. Segundo [8], algumas Oracle, mas não possui todas as funcionalidades da
características são válidas observar: versão para desktop. O FolhaNET, no entanto, foi
i. Quanto maior for a taxa de rejuvenescimento (r3), desenvolvido internamente pelos funcionários da
menor será o tempo de queda do sistema prefeitura.
(downtime); Após uma série de entrevistas, foi feita uma análise do
ii. Quando menor for a taxa de rejuvenescimento sistema Aplicativo CPD/RH que resultou nas seguintes
(r3), maior será o tempo de queda do sistema conclusões:
(downtime); i. O tempo médio entre as ocorrências de falhas é
iii. Quando o lambda (λ) for alto, o rejuvenescimento um mês;
tem que ser mais freqüente; ii. Quando acontece uma falha inesperada, demora
iv. Quando o lambda (λ) for alto, o aumento no em média 30 minutos para conseguir se
rejuvenescimento causa um maior downtime. recuperar;
A partir desse autômato mostrado na Figura 7, em [8] é iii. O tempo que o sistema sai do estado estável e
mostrado como calcular as probabilidades de alcançar entra em um estado de provável falha são sete
cada estado separadamente. dias;
Definindo como Pf com a probabilidade de alcançar o iv. Leva 10 minutos para fazer o rejuvenescimento,
estado de falha, Pr a probabilidade de alcançar o estado ou seja, se recuperar de um erro esperado;
de rejuvenescimento e L o tempo total que deve ser v. O custo médio do sistema fora do ar de maneira
analisado, temos o tempo de queda total (downtime) do imprevista é R$ 5000 por hora;
sistema por:
vi. O custo médio do rejuvenescimento é R$ 5 por
Downtime = (Pf + Pr) * L hora.
Também é possível calcular a partir do downtime, o custo Seguindo a mesma base de cálculos fornecida por [8],
total da manutenção. Tendo como Cf o custo caso ocorra chegamos à seguinte tabela:
uma queda não planejada e como Cr o custo do sistema
em estado de rejuvenescimento (queda planejada), temos
o custo total como:
Custo = (Pf*Cf+Pr*Cr)*L
É importante observar que podem existir casos em que o
downtime do sistema usando rejuvenescimento é maior
que o downtime dele caso não fosse feito o

7. iv. Sistemas que terão um maior tempo de vida.
Sem Uma vez por Uma vez a
rejuvenescimento mês cada duas E como desvantagem:
semanas i. Alto custo de desenvolvimento, se levar em conta
Downtime somente a parte financeira e não a qualidade do
4,86 5,68 7,03
(em horas) produto;
Custo total
R$ 24.310 R$ 18.944 R$ 10.072
ii. Tempo de inoperabilidade (downtime),
do downtime estatisticamente maior (na maioria dos casos), se
Tabela 1 – Análise do sistema Aplicativo CPD/RH comparado aos sistemas que não passam pelo
rejuvenescimento;
De acordo com a Tabela 1, podemos analisar que o tempo
que o sistema ficará fora do ar sem rejuvenescimento vai iii. Não se pode utilizar o rejuvenescimento em todo
ser menor que o tempo que ele ficaria se fosse feito uma tipo de sistema, pois uma análise profunda
vez por mês, que por sua vez seria ainda menor, do que se anterior deve ser feita.
fosse feito uma vez a cada duas semanas. Na análise do estudo de caso, viu-se a importância do
Como já foi dito anteriormente, se fosse analisar se deve rejuvenescimento no sistema Aplicativo CPD/RH, mas
ou não serem feitas praticas constantes de foi concluído que nem sempre um custo mais baixo de
rejuvenescimento nesse sistema baseando-se somente no manutenção significa um menor tempo de downtime.
tempo downtime, vê-se facilmente que seria desvantagem Notou-se também a clara importância de uma política de
o rejuvenescimento. Porém se for analisar o custo que o gerenciamento de projetos no setor de TIC da Prefeitura
sistema teria, pois a queda imprevista é muito mais cara Municipal de Aracaju e a conclusão foi que o Project
do que uma queda prevista (rejuvenescer), vê-se que o Office, se aplicado, poderia atender a essa falha no setor.
rejuvenescimento tem mais vantagem. Também políticas de rejuvenescimento aplicadas a esses
A partir disso vem o questionamento se prioriza o custo sistemas reduziriam o custo e conseqüentemente
ou o downtime. A resposta disso é que a grande maioria aumentariam o seu tempo de vida.
das organizações olha o custo como o fator mais 5.REFERÊNCIAS
importante. Logo, no exemplo do estudo de caso
proposto, concluímos que seria muito bom para a [1] Universidade Aberta. Rejuvenescimento de
prefeitura se fossem aplicadas praticas de Software. 2007. Disponível em:
rejuvenescimento no sistema Aplicativo CPD/RH. <http://www.moodle.univ-
ab.pt/moodle/mod/glossary/print.php?id=2243&mode=&
3.3.1Aplicação do Project Office hook=ALL&sortkey=&sortorder=&offset=-10>. Acesso
Analisando também um pouco mais do sistema em: 17 out. 2008.
FolhaNET na situação em que se encontra o setor de TIC [2] SILVA, Nuno Alberto Pereira da. Rejuvenescimento
na prefeitura, vimos que houve uma grande falha de
de Aplicações: Uma experiência com software de
administração e gerenciamento de projetos. seguros. Universidade do Minho, 2005. Disponível em: <
O FolhaNET foi desenvolvido com o objetivo de aliviar http://repositorium.sdum.uminho.pt/handle/1822/5635 >.
um pouco a demanda pelo Aplicativo CPD/RH, criando Acesso em: 17 out. 2008
assim funcionalidades repetidas, que só seriam acessadas [3] LABUTO, Gianncarla Cutini Barcellos. A gestão de
pela Web. Mas a falta de uma política de gerenciamento
Projetos e o Project Office. 2008. Disponível em:
de projetos adequada, fez com que o sistema nunca <http://www.ietec.com.br/site/techoje/categoria/detalhe_a
alcançasse um estado estável dentro da prefeitura. rtigo/103>. Acesso em: 17 out. 2008.
Hoje em dia, tanto o Aplicativo CPD/RH, como o [4] VAIDYANATHAN, Kalyanaraman; TRIVEDI ,
FolhaNET possuem código difícil de manutenção, graves Kishor S. A Comprehensive Model for Software
problemas nas suas funcionalidades e nem um nem outro Rejuvenation. 2005. Disponível em: <
atende completamente às necessidades plenas propostas. http://ieeexplore.ieee.org/iel5/8858/31216/01453531.pdf
Recomenda-se fortemente o inicio da prática do Project > Acesso em: 17 out. 2008.
Office na prefeitura como uma forma de gerenciar esses [5] AVRITZER Alberto ;BONDI Andre; GROTTKE
projetos. Isso poderá ser feito utilizando algumas das Michael ; TRIVEDI Kishor S. ; WEYUKER Elaine J.
ferramentas propostas anteriormente (seção 3.8) e a
Performance Assurance via Software Rejuvenation:
equipe que ficará responsável por isso poderá administrar Monitoring, Statistics and Algorithms. 2006.
o ciclo de rejuvenescimento desses softwares, sem nunca Disponível em: <
eliminar a possibilidade do desenvolvimento de um novo http://ieeexplore.ieee.org/iel5/10881/34248/01633532.pdf
sistema que resolva todos esses problemas. > Acesso em: 17 out. 2008.
4.CONSIDERAÇÕES FINAIS [6] MARCHIORO, Eliete. Um Estudo Sobre
Após análise da prática de rejuvenescimento, tem-se Rejuvenescimento de Software em Servidores Web
como principais vantagens encontradas: Apache. 2003. Disponível em:
<http://www1.capes.gov.br/estudos/dados/2003/4100101
i. Sistemas sempre atuais, de acordo com as novas
0/002/2003_002_41001010025P2_Teses.pdf >. Acesso
tecnologias;
em: 17 out. 2008.
ii. Sistemas com melhor manutenabilidade, baixo
[7] BAUMOTTE, Ana Cláudia. Project Office: como
custo de manutenção;
vender essa idéia na sua organização. 2008. Disponível
iii. Sistemas capazes de se adaptar facilmente à em: <
novas tecnologias;

8. http://www.pmimg.org.br/downloads/ProjectOffice.ppt>
Acesso em: 17 out. 2008.
[8] HUANG, Y.; KINTALA, C.; KOLETTIS, N.;
FULTON, N.D. Software rejuvenation: analysis,
module and applications, in: Proceedings of the 25th
International Symposium on Fault-Tolerance Computing
(FTCS-25), Pasadena, CA, USA, June 1995.
[9] BOBBIO, A.; SERENO, M.; ANGLANO C., 2001.
Fine grained software degradation models for optimal
rejuvenation policies. Performance Evaluation
[10] GARG, S.; PFENING, A.; PULIAFITO, A. ;
TELEK, M.; TRIVEDI, K.S. Modelling and analysis of
load and time-dependent software rejuvenation
policies, in: Proceedings of the Third International
Workshop on Performability Modeling of Computer and
Communication Systems (PMCCS3), Bloomingdale, IL,
September 1996, pp. 35–39.
[11] GARG, S.; PFENING, A.; PULIAFITO, A. ;
TELEK, M.; TRIVEDI, K.S. Analysis of software
rejuvenation using Markov regenerative stochastic
Petri net, in: Proceedings of the Sixth International
Symposium on Software Reliability Engineering
(ISSRE95), Toulouse, France, October 1995.
[12] PIEKARSKI, Ana ElisaTozetto ; QUINÁIA, Marcos
Antonio. Reengenharia de software: o que, por quê e
como. 2000. Disponível em: <
http://www.unicentro.br/editora/revistas/recen/v1n2/Reen
genharia.pdf>. Acesso em: 29 nov. 2008.
[13] ANQUETIL, Nicolas; OLIVEIRA, Káthia Marçal
de. Processo de Redocumentação: Uma Necessidade.
2002. Disponível em: <
http://www.ucb.br/prg/professores/anquetil/Publicacoes/s
bqs02.doc>. Acesso em: 29 Mai. 2008.
[14] WIKIPEDIA. Engenharia reversa de software.
2008. Disponível em:
<http://pt.wikipedia.org/wiki/Engenharia_reversa>.
Acesso em: 29 Mai. 2008
[15] WIKIPEDIA. Refatoração. 2008. Disponível em:
<http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A
3o>. Acesso em: 29 nov. 2008.
[16] METEX. 2008. Disponível em: <
http://www.metex.com>. Acesso em: 29 nov. 2008.
[17] LEGACYJ. 2008. Disponível em:
<http://www.legacyj.com>. Acesso em: 29 nov. 2008.
[18] NETEXPRESS. 2008. Disponível em: <
http://www.microfocus.com/products/netexpress>.
Acesso em: 29 nov. 2008.