Boa tarde pessoal,
Vou falar hoje sobre uma experiência que terminou como TCC de estudantes da
Universidade Federal de Florianópolis, é a utilização do RUP aplicado a
reengenharia de sistema.
O trabalho trada da experiência no uso da metodologia de desenvolvimento RUP
em um processo de reengenharia de sistemas. O RUP foi escolhido devido a suas
característica altamente adaptativa. e que se mostrou útil ao caso de uso
proposto pelo trabalho.
A reengenharia foi aplicada ao sistema da Associação de Professores da UFSC
desenvolvido em Microsoft Access e com pouca documentação.
Pressman como um dos prisma da reengenharia a criação de um produto com
funcionalidades adicionais e melhoras no sistema e na forma de manutenção dele,
sendo utilizado para a migração de sistemas legados com pouca documentação ou
migração de sistemas locais para sistemas baseados na internet.
Muitos pensam no RUP para utilização em projetos novos onde existem bem
definidas todas as fases do projeto porém como é mostrado no trabalho muitos
artefatos podem ser utilizados no processo de reengenharia.
O documento utiliza a ideia do Business Process Reengineering que é você
fazer a avaliação crítica de todo negócio existente e tentar encontrar
meios novos para sua reconstrução.
Também explica que projetos de reengenharia tem grandes chances de fracasso,
entre 50% a 70% segundo Jacobson, e o documento abordar segundo Pressman os
principais motivos desse fracasso.
Para utilização do RUP nesse cenário ou em qualquer outro é preciso manter
os princípios do RUP.
Também mesmo em um projeto de reengenharia deve-se criar os documentos de
Visão, Planejamento do Projeto, Avaliação de Riscos entre os outros artefatos
mínimos para projetos e definir os artefatos do sistema legado.
O levantamento de requisitos tem uma fase para identificação dos requisitos
dos sistema legado e sua adaptação para os requisitos atuais.
Durante a analise em que é feito a expansão dos casos de usos e eventos do
sistemas caso o sistema legado tenha interface definida a expansão do caso de
uso pode utilizar os casos de uso reais. Wazlawick aborda a falta de
necessidade para projetos de reengenharia já que a versão de caso de uso
essencial é para explorar sistemas desconhecido em que se precisa ter um
aprendizado para a construção de telas. Em projetos de reengenharia é indicado
manter a interface compatível com a antiga.
Quando se está no projeto os principais artefatos são os diagramas de
interação baseado nos diagramas de classe sendo construindo da mesma forma que
um processos de projeto baseado em engenharia normal.
Após o projeto é feita a implantação, durante a implantação encontra-se mais
dificuldades comparados a um projeto novo. Para Kruchten, sistemas feitos de
reengenharias trazem problemas como a conversão de dados, continuidade de
operação e re-treinamento do pessoal bem como a confiança do usuário no novo
sistema.
Kruchten alinha o fluxo de trabalho de reengenharia com as fases do RUP e os
documentos necessários a mais para cada fase.
concepção - documento dos artefatos a serem reconstruídos e iniciação do processo
de engenharia reversa para os artefatos de requisitos e análise.
elaboração – A elaboração aproveita os artefatos antigos e todos devem ser
revisados e incorporados.
construção - A fase de construção do RUP segue como a de um projeto de software de
engenharia normal. Os artefatos legados são implementados e atualizados.
transição - A fase de transição encontram-se os elementos mais delicados. Necessários
atenção para a migração de dados, a desativação do sistema que está sendo substituído.
No estudo de caso do trabalho os autores descrevem as atividades de todas as
fases do RUP que permitiu a reengenharia minimizando as chances de falhas ou
erros durantes o projeto.
A baixo vou reproduzir a conclusão que os autores tiveram sobre o estudo
realizado.
Conclusão
Um processo de reengenharia pode ser visto sob dois diferentes prismas, a reengenharia de negócios e a reengenharia de sistemas. A primeira, também chamada de BPR, é muito mais abrangente, envolve toda uma organização e acaba, em última instancia, levando também à segunda.
A reengenharia de sistemas, foco deste trabalho, pode ser vista como uma atividade composta, basicamente, dos seguintes passos: conhecer o software existente e as razões que levam à necessidade de uma reengenharia; fazer a engenharia reversa do sistema existente a fim de se obter conhecimento e documentação o bastante sobre ele para se realizar a construção de um novo sistema; e, realizar a construção do novo sistema partindo-se da documentação gerada com a engenharia reversa e dos requisitos que levaram ao processo de reengenharia.
Neste trabalho verificou-se o poder de adaptação do Rational Unified Process quando este pôde ser perfeitamente utilizado em um processo de reengenharia. Num primeiro momento, usou-se a fase de concepção do RUP para se estudar o sistema existente e levantar os requisitos que motivaram a realização da reengenharia.
Em seguida, foi possível se utilizar, com algumas pequenas adaptação, os fluxos de levantamento de requisitos, análise e projeto de RUP para se estudar e documentar o sistema existente a fim de preparar a base para a construção do novo sistema. Dentre as adaptação feitas pode-se citar:
• identificação de requisitos a partir da análise do sistema já existente; • identificação de conceitos a partir da estrutura de dados ou banco de dados do sistema legado;
• identificação dos casos de uso e consultas a partir da estrutura e dos processos dos sistema;
• expansão dos casos de uso diretamente para casos de uso reais utilizando-se como modelo de interface gráfica a interface do próprio sistema existente;
• elaboração dos contratos usando-se como base, além dos casos de uso, as funções do sistema legado.
A construção do sistema a partir dos artefatos gerados com o auxílio de uma engenharia reversa acaba sendo praticamente igual à construção de um sistema qualquer. Um dos grandes desafios de uma reengenharia surge no final, na implantação do sistema, quando deve-se tomar cuidado com a estratégia utilizada afim de se evitar problemas com os usuários finais.
O processo de reengenharia do sistema da APUFSC não foi completado principalmente por dois motivos: o pouco tempo de desenvolvimento deste trabalho e a falta de mão- de-obra para o desenvolvimento. Porém, mesmo não se tendo feito o processo todo, foi possível avaliar bem o uso do RUP em um projeto dessa natureza e algumas adaptações interessantes foram propostas.
