tees final
TRANSCRIPT
Grupo: Eduardo DóriaBruno LinsMarcus ViniciusDiego Calasans
“Até hoje, o foco da literatura vai no sentido de se ensinar a criar grandes soluções arquiteturais de software, no entanto, e cada vez mais, as necessidades de hoje e amanhã vão no sentido de se ser capaz de evoluir de sistemas existentes, ou legados, para grandes soluções.“
Joshua Kerievsky
Software desestruturado› Não obedece padrões
Ausência de separação entre camadas› Não possui arquitetura definida
Código “Spagheti”› Ausência de modularização
Termo “Software Rejuvenation” citado pela primeira vez em Junho 1995 por Huang no 25th International Symposium on Fault-Tolerance Computing, USA.
“Software rejuvenation is periodic preemptive rollback of continuously running applications to prevent failures in the future”
Evolução de diversos paradigmas relativos à Engenharia de Software
Capacidade de se adaptar às constantes necessidades
Condicionada pela base tecnológica
Características necessárias para um código saudável:› Grau de reutilização do código› Não duplicação do código› Testabilidade do código
Linguagens OO
Maioria dos Sistemas Legados não utilizam OO
Sistema diz-se Legado quando surgem novos requisitos aos quais o mesmo não consegue responder de forma eficaz.
Intervenção de forma gradual
• O rejuvenescimento de software tem a finalidade de melhorar a qualidade do software reduzindo os custos com sua manutenção.
• As técnicas mais utilizadas são:– Redocumentação– Reestruturação /Refatoração– Engenharia reversa– Reengenharia
Importância da documentação
Custo de Manutenção
Rotatividade de profissionais
Características básicas
› Baseado na engenharia reversa (código)
› Gerar documentação mínima necessária
› Buscar automatização quando possível
Modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.
Melhora no entendimento do código
Testes automatizados
Processo inverso da Engenharia de Software
Recuperar código-fonte
Exemplos de uso:› Cracks, Drivers, Samba (Linux)
Partindo-se do sistema existente (via código-fonte, interface ou ambiente), são abstraídas as suas funcionalidades e são construídos o modelo de análise e o projeto do software.
Pode-se utilizar a engenharia reversa
Relacionamentos no Ciclo de Desenvolvimento de Software (CHIKOFSKY e CROSS, 1990)
Software sempre atual Boa manutenabilidade Adaptabilidade Reusabilidade Evitar queda do sistema
Alto custo de desenvolvimento
DownTime maior na maioria dos casos
Não serve para todos os tipos de sistemas
Processo de envelhecimento› Degradação gradual da sua eficiência, que
ao longo do tempo pode levar a um estado de inutilidade
Causas› Vazamento de memória› Uso progressivo de discos de
armazenamento› Uso de estruturas e arquivos
desatualizados› Muitos erros de arredondamento numérico
O custo da queda imprevista de um software é muito maior do que uma “queda” curta e planejada
Aumenta o tempo de vida, trazendo muita economia
Prevenção reativa› Vê se a aplicação falha e toma a medida
correta› Reiniciar, recuperar, rollback, reordenar,
replay
Prevenção proativa e preventiva› Rejuvenescimento de software› Diferentes maneiras de prevenção, que
minimiza os danos colaterais
Modelo de transição do sistema sem o rejuvenescimento
Modelo de transição com o uso do rejuvenescimento
Pf =
Downtimew/o r(L) = Pf * L
Costw/o r(L) = Pf * L * cf
2111
1
rrr
24
34
111
rr
rr
r
Pr P*1
• Pp =
• Pf =
• Pr =
• P0 =
Prr P*34
Prr P*24
• Downtimew r(L) = (Pf + Pr) * L
• Costw r(L) = (Pf * cf + Pr * cr) * L
O objetivo é manter no So o maior tempo possível
R3 alta -> menor tempo de queda (downtime)
R3 baixa -> maior tempo de queda (downtime)
Lambda alto-> rejuvenescimento mais frequente
Lambda baixo -> rejuvenescimento aumenta o downtime
Tempo de falhas = 1 mês -> = 1/(1*30*24) Leva 30 min para recuperar um erro não
esperado; r1 = 2 Tempo So->Sp = 7 dias; r2 =1/(7*24) Leva 10 min para recuperar um erro
esperado (rejuvenescimento); r3 = 6 Custo médio do sistema fora do ar, cf, is
R$5,000/hora Custo medio do rejuvenescimento, cr, is
R$5/hora
Sem rejuvenescimento
(r4 = 0)
Uma vez por mês
r4 = 1/(20*24)
Uma vez a cada duas semanas
r4 =1/(4*24)
Downtime (em horas) 4.86 5.68 7.03
Custo total do Downtime
R$ 24.310 R$ 18.944 R$ 10.072
Um modelo baseado em caixa-preta Precisam ter os valores médios das
diferentes transições Não leva em conta a performance do
sistema
Um intervalo de rejuvenescimento periódico e fixo
Usam redes de Petri para observar o comportamento do sistema
Não leva em conta a performance do sistema
É possível identificar a performance do sistema de acordo com observações
O processo de degradação vem de uma seqüência sucessiva de falhas e quebras
Existe um parâmetro de observação que vai decidir se o sistema entrou em um estado de “crash”
Dois critérios decidem:› O risco da decisão que precisa ser tomada
de modo que ocorrer um risco antes do rejuvenescimento seja inferior a um nível de risco premeditado
› Os alertas dos limiares baseados nos parâmetros (S(t) -> índice de degradação)
Baseado na observação do comportamento do sistema em espaços iguais de tempo
Baseados na quantidade de falhas encontradas em um intervalo de tempo
Regras para renovar o sistema antes que ele chegue num estado limiar
Dois tipos de políticas› Baseadas em riscos premeditados› Baseadas em alertas de limiares
A escolha depende da equipe e da instituição
O papéis do pessoal da equipe seguem o mesmo modelo definido pela instituição e pela metodologia
Micro Focus Net Express LegacyJ Metex
Permite integração de aplicações escritas em COBOL com tecnologias baseadas em J2EE
Pouca ou nenhuma modificação no código
Permite utilização de EJB Permite Edição de código utilizando
ECLIPSE
Moderniza aplicações legadas escritas em COBOL
Reutiliza códigos existentes para criar aplicações modernas
Expões aplicações COBOL como WEB Services
Torna uma aplicação COBOL compatível com Servidores JAVA
Compartilha dados de aplicações diferentes através de XML
Automatiza completamente a reconstrução de softwares legados
Gera código de alta qualidade Gera aplicações Java ou .NET Pode gerar aplicações pra WEB PowerBuilder, Oracle Forms, Forte, VB
e Centura Não é apenas um migrador de código
Transformação Reengenharia Documentação UML Migração de Banco de Dados Habilitação para WEB
Revisão de arquitetura – Discussão com o cliente sobre a nova arquitetura;
Conversão automática de código – A ferramenta converte o código automaticamente;
Utilização de ferramentas avançadas para completar o código – Utilização de algumas ferramentas avançadas do Metex para completar a conversão;
Teste de integração e Verificação – O Metex também oferece ferramentas para verificação e testes do código gerado;
Teste de aceitação de usuário – Ao final do processo é utilizado um rastreador de bugs online para correção de possíveis erros.
Disponibiliza a aplicação na WEB Move as funções do negócio para
dispositivos Wireless Maior competitividade Reduz custos operacionais
Nova Funcionalidade› Necessidade de implementação de uma
nova funcionalidade ou alteração dos requisitos de uma funcionalidade já implementada
› Normalmente, o cliente identifica uma nova necessidade não atendida pelo sistema
Recolher histórias dos clientes› Tem como objetivo identificar os requisitos
da nova funcionalidade.› São realizadas reuniões com os
desenvolvedores e os clientes.› Tem como resultado uma lista de requisitos
que devem ser atendidos por essa nova funcionalidade.
Desenho (Design)› Representação da nova funcionalidade
através de modelos.› Deve ser usada para a validação.
Conseguir uma melhor percepção dos impactos do desenvolvimento de novas funcionalidades.
Escrita de Testes› Descreve o comportamento esperado para
a nova funcionalidade› A especificação dos testes deve ser feita
antes da codificação› Ao iniciar a codificação, os testes serviram
para o desenvolvedor saber o objetivo da nova funcionalidade
Codificação› Codifica a nova funcionalidade uma
linguagem de programação.› O uso de padrões na codificação melhora a
legibilidade no código e propõe soluções para problemas comuns.
› Normalmente, não se é usado padrões de codificação nas primeiras iterações. Refactoring
Execução de Testes› Fase essencial no desenvolvimento de
software› Garante que o comportamento do sistema
continua a funcionar de acordo com os seus requisitos
Produto› Cada iteração termina com a geração de
uma nova versão do sistema.› Não deve ter um grande volume de
alterações
Na área de TI, as mudanças tem sido cada vez mais constantes.
Aumento no número de projetos e com complexidades cada vez maiores.
A empresa precisa manter bem organizado o controle sobre os seus projetos.
Desejo de melhorar a taxa de sucesso de projetos, que continuamente se tornam mais complexos
Necessidade de aliviar o gerente de projetos de tarefas administrativas associadas ao gerenciamento de um projeto.
É uma área da empresa que possui a visão de todos os projetos.
Tem como objetivos:› Melhoria da eficiência no planejamento e
condução dos projetos› Informação rápida sobre os projetos
existentes› Auxílio nas decisões a serem tomadas
sobre o futuro de cada projeto
Padronização de uma metodologia› Defini uma ferramenta e métodos de
controle e acompanhamento dos projetos.› Manter essas ferramentas e métodos
atualizados e adaptados às necessidades da empresa
› Realizar o treinamento dos funcionários e mantê-los atualizados na metodologia e ferramentas
Avaliação dos recursos de projetos› São analisados todos os recursos do
projeto: Humano Financeiro Tempo Material
› É importante para a análise de desempenho dos projetos e a priorização dos mesmos.
Planejamento de Projetos› Tem como objetivo manter cada projeto
organizado, priorizado, distribuído em áreas e devidamente documentado
› É possível se obter também dados históricos que auxiliam a elaboração de novos planos.
Gerenciamento de Projetos› Definir melhores práticas de trabalho para
facilitar o gerenciamento Revisão e Análise de Projetos
› Constante revisão das atividades Custo e prazo Impactos no desempenho
Y. Huang, C. Kintala, N. Kolettis, N.D. Fulton, Software rejuvenation: analysis, module and applications, in: Proceedings of the 25th International Symposium on Fault-Tolerance Computing (FTCS-25), Pasadena, CA, USA, June 1995.
Bobbio, A., M. Sereno and C. Anglano, 2001. Fine grained software degradation models for optimal rejuvenation policies. Performance Evaluation
S. Garg, A. Pfening, A. Puliafito, M. Telek, K.S. Trivedi, 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.
S. Garg, A. Puliafito, M. Telek, K.S. Trivedi, 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.
Universidade Aberta. Rejuvenescimento de Software . Disponível em: <http://www.moodle.univ-ab.pt/moodle/mod/glossary/print.php?id=2243&mode=&hook=ALL&sortkey=&sortorder=&offset=-10>. Acesso em: 17 out. 2008.
SILVA, Nuno Alberto Pereira da. Rejuvenescimento de Aplicações: Uma experiência com software de seguros. Universidade do Minho, 2005. Disponível em: < http://repositorium.sdum.uminho.pt/handle/1822/5635 >. Acesso em: 17 out. 2008
LABUTO, Gianncarla Cutini Barcellos. A gestão de Projetos e o Project Office. Disponível em: <http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/103>. Acesso em: 17 out. 2008.
VAIDYANATHAN, Kalyanaraman; TRIVEDI , Kishor S. A Comprehensive Model for Software Rejuvenation, 2005. Disponivel em: < http://ieeexplore.ieee.org/iel5/8858/31216/01453531.pdf > Acesso em: 17 out. 2008.
AVRITZER Alberto ;BONDI Andre; GROTTKE Michael ; TRIVEDI Kishor S. ; WEYUKER Elaine J. Performance Assurance via Software Rejuvenation: Monitoring, Statistics and Algorithms, 2006. Disponivel em: < http://ieeexplore.ieee.org/iel5/10881/34248/01633532.pdf> Acesso em: 17 out. 2008.
MARCHIORO, Eliete. UM ESTUDO SOBRE REJUVENESCIMENTO DE SOFTWARE EM SERVIDORES WEB APACHE, 2003. Disponivel em: <http://www1.capes.gov.br/estudos/dados/2003/41001010/002/2003_002_41001010025P2_Teses.pdf >. Acesso em: 17 out. 2008.
• BAUMOTTE, Ana CláudiaBAUMOTTE, Ana Cláudia. . Project Office: como vender essa idéia na sua organização. Disponível em: < http://www.pmimg.org.br/downloads/ProjectOffice.ppt> . Acesso em: 17 out. 2008.
• PIEKARSKI, Ana ElisaTozetto ; QUINÁIA, Marcos Antonio. Reengenharia de software: o que, por quê e como. Disponível em: < http://www.unicentro.br/editora/revistas/recen/v1n2/Reengenharia.pdf>. Acesso em: 29 nov. 2008.
• ANQUETIL, Nicolas; OLIVEIRA, Káthia Marçal de. Processo de Redocumentação: Uma Necessidade. Disponível em: < http://www.ucb.br/prg/professores/anquetil/Publicacoes/sbqs02.doc>. Acesso em: 29 Mai. 2008.
• WIKIPEDIA. Engenharia reversa de software. Disponível em: <http://pt.wikipedia.org/wiki/Engenharia_reversa>. Acesso em: 29 Mai. 2008
• WIKIPEDIA. Refatoração. Disponível em: <http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o>. Acesso em: 29 Mai. 2008.