Tees Final

717 views

Published on

Apresentação Final Rejuvenescimento de Software

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
717
On SlideShare
0
From Embeds
0
Number of Embeds
60
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Tees Final

    1. 1. Grupo: Eduardo Dória Bruno Lins Marcus Vinicius Diego Calasans
    2. 2. <ul><li>“ 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.“ </li></ul><ul><li>Joshua Kerievsky </li></ul>
    3. 3. <ul><li>Software desestruturado </li></ul><ul><ul><li>Não obedece padrões </li></ul></ul><ul><li>Ausência de separação entre camadas </li></ul><ul><ul><li>Não possui arquitetura definida </li></ul></ul><ul><li>Código “Spagheti” </li></ul><ul><ul><li>Ausência de modularização </li></ul></ul>
    4. 4. <ul><li>Termo “ Software Rejuvenation ” citado pela primeira vez em Junho 1995 por Huang no 25th International Symposium on Fault-Tolerance Computing, USA . </li></ul><ul><li>“ Software rejuvenation is periodic preemptive rollback of continuously running applications to prevent failures in the future” </li></ul>
    5. 5. <ul><li>Evolução de diversos paradigmas relativos à Engenharia de Software </li></ul><ul><li>Capacidade de se adaptar às constantes necessidades </li></ul><ul><li>Condicionada pela base tecnológica </li></ul>
    6. 6. <ul><li>Características necessárias para um código saudável: </li></ul><ul><ul><li>Grau de reutilização do código </li></ul></ul><ul><ul><li>Não duplicação do código </li></ul></ul><ul><ul><li>Testabilidade do código </li></ul></ul><ul><li>Linguagens OO </li></ul>
    7. 7. <ul><li>Maioria dos Sistemas Legados não utilizam OO </li></ul><ul><li>Sistema diz-se Legado quando surgem novos requisitos aos quais o mesmo não consegue responder de forma eficaz. </li></ul><ul><li>Intervenção de forma gradual </li></ul>
    8. 8. <ul><li>O rejuvenescimento de software tem a finalidade de melhorar a qualidade do software reduzindo os custos com sua manutenção. </li></ul><ul><li>As técnicas mais utilizadas são: </li></ul><ul><ul><li>Redocumentação </li></ul></ul><ul><ul><li>Reestruturação /Refatoração </li></ul></ul><ul><ul><li>Engenharia reversa </li></ul></ul><ul><ul><li>Reengenharia </li></ul></ul>
    9. 9. <ul><li>Importância da documentação </li></ul><ul><li>Custo de Manutenção </li></ul><ul><li>Rotatividade de profissionais </li></ul>
    10. 10. <ul><li>Características básicas </li></ul><ul><ul><li>Baseado na engenharia reversa (código) </li></ul></ul><ul><ul><li>Gerar documentação mínima necessária </li></ul></ul><ul><ul><li>Buscar automatização quando possível </li></ul></ul>
    11. 11. <ul><li>Modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo. </li></ul><ul><li>Melhora no entendimento do código </li></ul><ul><li>Testes automatizados </li></ul>
    12. 12. <ul><li>Processo inverso da Engenharia de Software </li></ul><ul><li>Recuperar código-fonte </li></ul><ul><li>Exemplos de uso: </li></ul><ul><ul><li>Cracks, Drivers, Samba (Linux) </li></ul></ul>
    13. 13. <ul><li>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. </li></ul><ul><li>Pode-se utilizar a engenharia reversa </li></ul>
    14. 14. Relacionamentos no Ciclo de Desenvolvimento de Software (CHIKOFSKY e CROSS, 1990)
    15. 15. <ul><li>Software sempre atual </li></ul><ul><li>Boa manutenabilidade </li></ul><ul><li>Adaptabilidade </li></ul><ul><li>Reusabilidade </li></ul><ul><li>Evitar queda do sistema </li></ul>
    16. 16. <ul><li>Alto custo de desenvolvimento </li></ul><ul><li>DownTime maior na maioria dos casos </li></ul><ul><li>Não serve para todos os tipos de sistemas </li></ul>
    17. 17. <ul><li>Processo de envelhecimento </li></ul><ul><ul><li>Degradação gradual da sua eficiência, que ao longo do tempo pode levar a um estado de inutilidade </li></ul></ul><ul><li>Causas </li></ul><ul><ul><li>Vazamento de memória </li></ul></ul><ul><ul><li>Uso progressivo de discos de armazenamento </li></ul></ul><ul><ul><li>Uso de estruturas e arquivos desatualizados </li></ul></ul><ul><ul><li>Muitos erros de arredondamento numérico </li></ul></ul>
    18. 18. <ul><li>O custo da queda imprevista de um software é muito maior do que uma “queda” curta e planejada </li></ul><ul><li>Aumenta o tempo de vida, trazendo muita economia </li></ul>
    19. 19. <ul><li>Prevenção reativa </li></ul><ul><ul><li>Vê se a aplicação falha e toma a medida correta </li></ul></ul><ul><ul><li>Reiniciar, recuperar, rollback, reordenar, replay </li></ul></ul><ul><li>Prevenção proativa e preventiva </li></ul><ul><ul><li>Rejuvenescimento de software </li></ul></ul><ul><ul><li>Diferentes maneiras de prevenção, que minimiza os danos colaterais </li></ul></ul>
    20. 20. Modelo de transição do sistema sem o rejuvenescimento Modelo de transição com o uso do rejuvenescimento
    21. 21. <ul><li>Pf = </li></ul><ul><li>Downtime w/o r (L) = P f * L </li></ul><ul><li>Cost w/o r (L) = P f * L * c f </li></ul>
    22. 22. <ul><li>P p = </li></ul><ul><li>P f = </li></ul><ul><li>P r = </li></ul><ul><li>P 0 = </li></ul><ul><li>Downtime w r (L) = (P f + P r ) * L </li></ul><ul><li>Cost w r (L) = (P f * c f + P r * c r ) * L </li></ul>
    23. 23. <ul><li>O objetivo é manter no So o maior tempo possível </li></ul><ul><li>R3 alta -> menor tempo de queda (downtime) </li></ul><ul><li>R3 baixa -> maior tempo de queda (downtime) </li></ul><ul><li>Lambda alto-> rejuvenescimento mais frequente </li></ul><ul><li>Lambda baixo -> rejuvenescimento aumenta o downtime </li></ul>
    24. 24. <ul><li>Tempo de falhas = 1 mês ->  = 1/(1*30*24) </li></ul><ul><li>Leva 30 min para recuperar um erro não esperado; r 1 = 2 </li></ul><ul><li>Tempo So->Sp = 7 dias; r 2 =1/(7*24) </li></ul><ul><li>Leva 10 min para recuperar um erro esperado (rejuvenescimento); r 3 = 6 </li></ul><ul><li>Custo médio do sistema fora do ar, c f , is R$5,000/hora </li></ul><ul><li>Custo medio do rejuvenescimento, c r , is R$5/hora </li></ul>
    25. 25. Sem rejuvenescimento (r 4 = 0) Uma vez por mês r 4 = 1/(20*24) Uma vez a cada duas semanas r 4 =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
    26. 26. <ul><li>Um modelo baseado em caixa-preta </li></ul><ul><li>Precisam ter os valores médios das diferentes transições </li></ul><ul><li>Não leva em conta a performance do sistema </li></ul>
    27. 27. <ul><li>Um intervalo de rejuvenescimento periódico e fixo </li></ul><ul><li>Usam redes de Petri para observar o comportamento do sistema </li></ul><ul><li>Não leva em conta a performance do sistema </li></ul>
    28. 28. <ul><li>É possível identificar a performance do sistema de acordo com observações </li></ul><ul><li>O processo de degradação vem de uma seqüência sucessiva de falhas e quebras </li></ul><ul><li>Existe um parâmetro de observação que vai decidir se o sistema entrou em um estado de “crash” </li></ul>
    29. 29. <ul><li>Dois critérios decidem: </li></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Os alertas dos limiares baseados nos parâmetros (S(t) -> índice de degradação) </li></ul></ul>
    30. 30. <ul><li>Baseado na observação do comportamento do sistema em espaços iguais de tempo </li></ul><ul><li>Baseados na quantidade de falhas encontradas em um intervalo de tempo </li></ul>
    31. 31. <ul><li>Regras para renovar o sistema antes que ele chegue num estado limiar </li></ul><ul><li>Dois tipos de políticas </li></ul><ul><ul><li>Baseadas em riscos premeditados </li></ul></ul><ul><ul><li>Baseadas em alertas de limiares </li></ul></ul>
    32. 32. <ul><li>A escolha depende da equipe e da instituição </li></ul><ul><li>O papéis do pessoal da equipe seguem o mesmo modelo definido pela instituição e pela metodologia </li></ul>
    33. 33. <ul><li>Micro Focus Net Express </li></ul><ul><li>LegacyJ </li></ul><ul><li>Metex </li></ul>
    34. 34. <ul><li>Permite integração de aplicações escritas em COBOL com tecnologias baseadas em J2EE </li></ul><ul><li>Pouca ou nenhuma modificação no código </li></ul><ul><li>Permite utilização de EJB </li></ul><ul><li>Permite Edição de código utilizando ECLIPSE </li></ul>
    35. 35. <ul><li>Moderniza aplicações legadas escritas em COBOL </li></ul><ul><li>Reutiliza códigos existentes para criar aplicações modernas </li></ul><ul><li>Expões aplicações COBOL como WEB Services </li></ul><ul><li>Torna uma aplicação COBOL compatível com Servidores JAVA </li></ul><ul><li>Compartilha dados de aplicações diferentes através de XML </li></ul>
    36. 36. <ul><li>Automatiza completamente a reconstrução de softwares legados </li></ul><ul><li>Gera código de alta qualidade </li></ul><ul><li>Gera aplicações Java ou .NET </li></ul><ul><li>Pode gerar aplicações pra WEB </li></ul><ul><li>PowerBuilder, Oracle Forms, Forte, VB e Centura </li></ul><ul><li>Não é apenas um migrador de código </li></ul>
    37. 37. <ul><li>Transformação </li></ul><ul><li>Reengenharia </li></ul><ul><li>Documentação UML </li></ul><ul><li>Migração de Banco de Dados </li></ul><ul><li>Habilitação para WEB </li></ul>
    38. 38. <ul><li>Revisão de arquitetura – Discussão com o cliente sobre a nova arquitetura; </li></ul><ul><li>Conversão automática de código – A ferramenta converte o código automaticamente; </li></ul><ul><li>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; </li></ul>
    39. 39. <ul><li>Teste de integração e Verificação – O Metex também oferece ferramentas para verificação e testes do código gerado; </li></ul><ul><li>Teste de aceitação de usuário – Ao final do processo é utilizado um rastreador de bugs online para correção de possíveis erros. </li></ul>
    40. 41. <ul><li>Disponibiliza a aplicação na WEB </li></ul><ul><li>Move as funções do negócio para dispositivos Wireless </li></ul><ul><li>Maior competitividade </li></ul><ul><li>Reduz custos operacionais </li></ul>
    41. 45. <ul><li>Nova Funcionalidade </li></ul><ul><ul><li>Necessidade de implementação de uma nova funcionalidade ou alteração dos requisitos de uma funcionalidade já implementada </li></ul></ul><ul><ul><li>Normalmente, o cliente identifica uma nova necessidade não atendida pelo sistema </li></ul></ul>
    42. 46. <ul><li>Recolher histórias dos clientes </li></ul><ul><ul><li>Tem como objetivo identificar os requisitos da nova funcionalidade. </li></ul></ul><ul><ul><li>São realizadas reuniões com os desenvolvedores e os clientes. </li></ul></ul><ul><ul><li>Tem como resultado uma lista de requisitos que devem ser atendidos por essa nova funcionalidade. </li></ul></ul>
    43. 47. <ul><li>Desenho (Design) </li></ul><ul><ul><li>Representação da nova funcionalidade através de modelos. </li></ul></ul><ul><ul><li>Deve ser usada para a validação. </li></ul></ul><ul><ul><ul><li>Conseguir uma melhor percepção dos impactos do desenvolvimento de novas funcionalidades. </li></ul></ul></ul>
    44. 48. <ul><li>Escrita de Testes </li></ul><ul><ul><li>Descreve o comportamento esperado para a nova funcionalidade </li></ul></ul><ul><ul><li>A especificação dos testes deve ser feita antes da codificação </li></ul></ul><ul><ul><li>Ao iniciar a codificação, os testes serviram para o desenvolvedor saber o objetivo da nova funcionalidade </li></ul></ul>
    45. 49. <ul><li>Codificação </li></ul><ul><ul><li>Codifica a nova funcionalidade uma linguagem de programação. </li></ul></ul><ul><ul><li>O uso de padrões na codificação melhora a legibilidade no código e propõe soluções para problemas comuns. </li></ul></ul><ul><ul><li>Normalmente, não se é usado padrões de codificação nas primeiras iterações. </li></ul></ul><ul><ul><ul><li>Refactoring </li></ul></ul></ul>
    46. 50. <ul><li>Execução de Testes </li></ul><ul><ul><li>Fase essencial no desenvolvimento de software </li></ul></ul><ul><ul><li>Garante que o comportamento do sistema continua a funcionar de acordo com os seus requisitos </li></ul></ul>
    47. 51. <ul><li>Produto </li></ul><ul><ul><li>Cada iteração termina com a geração de uma nova versão do sistema. </li></ul></ul><ul><ul><li>Não deve ter um grande volume de alterações </li></ul></ul>
    48. 52. <ul><li>Na área de TI, as mudanças tem sido cada vez mais constantes. </li></ul><ul><li>Aumento no número de projetos e com complexidades cada vez maiores. </li></ul><ul><li>A empresa precisa manter bem organizado o controle sobre os seus projetos. </li></ul>
    49. 53. <ul><li>Desejo de melhorar a taxa de sucesso de projetos, que continuamente se tornam mais complexos </li></ul><ul><li>Necessidade de aliviar o gerente de projetos de tarefas administrativas associadas ao gerenciamento de um projeto. </li></ul>
    50. 54. <ul><li>É uma área da empresa que possui a visão de todos os projetos. </li></ul><ul><li>Tem como objetivos: </li></ul><ul><ul><li>Melhoria da eficiência no planejamento e condução dos projetos </li></ul></ul><ul><ul><li>Informação rápida sobre os projetos existentes </li></ul></ul><ul><ul><li>Auxílio nas decisões a serem tomadas sobre o futuro de cada projeto </li></ul></ul>
    51. 55. <ul><li>Padronização de uma metodologia </li></ul><ul><ul><li>Defini uma ferramenta e métodos de controle e acompanhamento dos projetos. </li></ul></ul><ul><ul><li>Manter essas ferramentas e métodos atualizados e adaptados às necessidades da empresa </li></ul></ul><ul><ul><li>Realizar o treinamento dos funcionários e mantê-los atualizados na metodologia e ferramentas </li></ul></ul>
    52. 56. <ul><li>Avaliação dos recursos de projetos </li></ul><ul><ul><li>São analisados todos os recursos do projeto: </li></ul></ul><ul><ul><ul><li>Humano </li></ul></ul></ul><ul><ul><ul><li>Financeiro </li></ul></ul></ul><ul><ul><ul><li>Tempo </li></ul></ul></ul><ul><ul><ul><li>Material </li></ul></ul></ul><ul><ul><li>É importante para a análise de desempenho dos projetos e a priorização dos mesmos. </li></ul></ul>
    53. 57. <ul><li>Planejamento de Projetos </li></ul><ul><ul><li>Tem como objetivo manter cada projeto organizado, priorizado, distribuído em áreas e devidamente documentado </li></ul></ul><ul><ul><li>É possível se obter também dados históricos que auxiliam a elaboração de novos planos. </li></ul></ul>
    54. 58. <ul><li>Gerenciamento de Projetos </li></ul><ul><ul><li>Definir melhores práticas de trabalho para facilitar o gerenciamento </li></ul></ul><ul><li>Revisão e Análise de Projetos </li></ul><ul><ul><li>Constante revisão das atividades </li></ul></ul><ul><ul><ul><li>Custo e prazo </li></ul></ul></ul><ul><ul><ul><li>Impactos no desempenho </li></ul></ul></ul>
    55. 59. <ul><li>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. </li></ul><ul><li>Bobbio, A., M. Sereno and C. Anglano, 2001. Fine grained software degradation models for optimal rejuvenation policies . Performance Evaluation </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    56. 60. <ul><li>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. </li></ul><ul><li>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 </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    57. 61. <ul><li>BAUMOTTE, 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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>WIKIPEDIA. Engenharia reversa de software. Disponível em: <http://pt.wikipedia.org/wiki/Engenharia_reversa>. Acesso em: 29 Mai. 2008 </li></ul><ul><li>WIKIPEDIA. Refatoração. Disponível em: <http://pt.wikipedia.org/wiki/Refatora%C3%A7%C3%A3o>. Acesso em: 29 Mai. 2008. </li></ul>

    ×