Esta página es de solo lectura. Puedes ver la fuente pero no puedes cambiarla. Pregunta a tu administrador si crees que esto es incorrecto.

<h1>ALTERNATIVAS DE SOLUCIÓN</h1> <div class="level1"> <p> Con base en reuniones y entrevistas con el grupo de trabajo se plantearon diversas alternativas de acción, a saber: </p> <ol> <li class="level1"> Intentar integrar las aplicaciones existentes</li> <li class="level2"> Utilizar como base un software existente y modificarlo para dar alcance a la funcionalidad actual</li> <li class="level2"> Reescribir las aplicaciones para integrarlas en un solo sistema unificado</li> </ol> </div> <h2>Integrar las aplicaciones existentes</h2> <div class="level2"> <p> Esta opción se descarto tras analizar el estado actual del sistema, debido a la poco homogeneidad entre las diferentes aplicaciones que conforman el sistema. Como se plasma en el análisis ASIS (Poner referencia), existen 28 aplicaciones diferentes, con 2 motores de bases distintos, bases de datos separadas e incluso dos lenguajes de programación. Por tanto, el esfuerzo de integrar estas aplicaciones hubiera resultado mucho mayor al necesario para llevar a cabo alguna de las dos soluciones de reimplementación </p> </div> <h2>Utilizar una solución existente</h2> <div class="level2"> <p> Se evaluaron plataformas como Odoo y Liferay para reimplementar el sistema, </p> <p> El sistema Odoo fue descartado por la poca experiencia del grupo de trabajo en el lenguaje de programación Python y en el framework mismo, además se concluyó de que el framework podía no ser lo suficiente flexible para acomodar los requisitos funcionales identificados. </p> <p> El sistema de portales Liferay fue considerado y estudiado, sobretodo porque podía proporcionar inmediatamente características como el manejo de usuarios, y funcionalidades de interacción con el usuario como blogs, chats, listas de correo, entre otras, sin embargo, se evaluó que aunque estas características son deseables, se debía hacer énfasis en las funcionalidades que daban soporte a lo misional, el reimplementar estas funcionalidades misionales en forma de portales hubiera significado un mayor esfuerzo respecto a utilizar una arquitectura Web tradicional, además se observó que el sistema Liferay demanda una gran cantidad de recursos que hubiera ido en detrimento de la escalabilidad y rendimiento del sistema. </p> <p> Tras este análisis se concluyó que utilizar una solución existente no resultaba viable. </p> </div> <h2>Reescribir las aplicaciones en una sistema unificado</h2> <div class="level2"> <p> Descartadas las otras opciones, se concluyó que la alternativa más viable es reimplementar las funcionalidades misionales en un sistema unificado, con una base de datos única, bajo una arquitectura Web estilo SOA. Existen dos alternativas, ambas basadas en J2EE pero difiriendo en los mecanismos de renderización Web, la primera utiliza servicios REST que alimentan una interfaz de usuario ejecutada completamente en el navegador, la segunda se basa en el estilo tradicional de aplicaciones J2EE donde se utiliza un framework de presentación (JSF) que genera las interfaces de usuario en el servidor. </p> <p> Tras hacer un análisis de los atributos de calidad más relevantes del sistema se propone la arquitectura descrita en <a href="/cnscwiki/doku.php?id=ea:tobe:aplicaciones:sigeca:arquitectura" class="wikilink1" title="ea:tobe:aplicaciones:sigeca:arquitectura">:ea:tobe:aplicaciones:sigeca:arquitectura</a> </p> </div> <h1>PLAN DE ACCIÓN</h1> <div class="level1"> <p> Una vez determinada la alternativa de implementación, se formuló un plan de acción a partir del análisis TOBE del sistema, este plan de acción está guiado por la formulación del proyecto en la entidad y por la metodología de trabajo ágil, sobretodo pensando en obtener resultados de la forma más rápida y eficiente posible, el plan de acción se detalla entonces en </p> <p> <a href="/cnscwiki/doku.php?id=ea:tobe:aplicaciones:sigeca" class="wikilink1" title="ea:tobe:aplicaciones:sigeca">:ea:tobe:aplicaciones:sigeca</a> </p> </div>