MISW4410
Modernización de Software

 

Modernización de software

 

Nombre del curso: Modernización de Software
Course Name: Modernización de Software
Créditos: 2
Profesor: Kelly Garces
Fecha: 4 de junio al Julio 27
Días: M – 5:30 pm a 6:50 pm Virtual


Descripción

Durante su evolución una aplicación de software pasa por etapas de:

  1. Construcción
  2. Mantenimiento/actualización

Sin embargo, algunas veces factores como altos costos de mantenimiento, deuda técnica, inhabilidad para satisfacer los requerimientos y regulaciones, incompatibilidad con otros sistemas, cese de soporte por proveedores y falta de programadores con conocimiento de tecnologías legado cuestiona a los equipos de desarrollo alrededor de la pregunta: ¿apagamos esta aplicación para construirla desde cero?

En algunos casos la mejor alternativa es esa: construir todos los artefactos de software desde cero, pero en otros casos es tanto el conocimiento que encapsula el código legado y el hecho de tener tiempo y recursos limitados que hacen que esta opción sea inviable. Para este último caso puede explorarse la opción de modernizar lo existente.

La modernización de software consiste en transformar una aplicación de una arquitectura as-is a una arquitectura to-be, pero conservando lo máximo que se pueda del conocimiento del negocio.

La modernización de software cubre dos fases: 1) ingeniería inversa (reverse); y 2) ingeniería hacia adelante (forward). Ambas pudiéndose desarrollar de forma manual o (semi)automática.

El propósito de la primera es ayudar a entender el sistema actual a través de “vistas de software”. La obtención de estas vistas es importante porque en muchos casos no se cuenta con documentación de arquitectura actualizada ni tampoco se tiene acceso a las personas que construyeron inicialmente el sistema; lo único que se es el código. Cada vista es una representación (modelo) de alto nivel de la arquitectura as-is, por ej.., módulos del sistema, tablas de la base de datos, etc. Una vez se tiene un entendimiento de la arquitectura se pueden tomar decisiones de lo que se quiere tener en la arquitectura to-be y plasmarlo en las vistas. Las decisiones pueden ser rearquitecturar los módulos funcionales, suprimir código muerto, cambiar aspectos de la interfaz gráfica, entre otras.

El propósito de la segunda fase es transformar las vistas de software (sobre las cuales se tomaron decisiones) en artefactos de software que representan la aplicación modernizada.

Tecnologías principales

  • MPS de Jetbrains
  • Servicios de modernización de algunos fabricantes

Metodología del curso

A través de un caso de estudio de modernización de un monolito a microservicios en la nube se estudiarán diversas herramientas existentes para (semi)automatizar la fase de ingeniería inversa. Luego, se experimentará cómo se pasa, a nivel de diseño, de una arquitectura as-is a una to-be. Cerrando con una prueba de concepto en donde los estudiantes transformarán (migrarán) manualmente una pequeña parte del sistema para validar que la arquitectura to-be es técnicamente viable y satisface los requerimientos de calidad que motivaron la modernización.