Evolución y Mantenimiento de Software: Scrum y Reingeniería
Evolución y Mantenimiento de Software
1. Sustitución de Sistemas Heredados
La sustitución de un sistema heredado debe considerarse cuando factores como la adquisición de nuevo hardware impidan que el sistema anterior continúe en operación, o cuando la disponibilidad de sistemas comerciales permita desarrollar un nuevo sistema a un costo razonable.
9. Problemas con el Software de Soporte y Sustitución de Sistemas
Desde una perspectiva técnica, la calidad del software se ve influenciada tanto por la aplicación en sí como por el software y hardware de soporte. Problemas con el software de soporte pueden obligar a una organización a sustituir sus sistemas heredados. Es crucial evaluar estos componentes para tomar decisiones informadas sobre el futuro del sistema.
10. Responsabilidad de los Ingenieros en la Mantenibilidad del Código
Sí, los ingenieros tienen la responsabilidad de producir código mantenible y adaptable. Las metodologías de desarrollo y las buenas prácticas recomiendan generar código que pueda ser modificado con facilidad a lo largo del tiempo.
2. Scrum: Una Metodología Ágil
Scrum es una metodología para la gestión de proyectos que se centra en las necesidades del usuario final. Las características, conocidas como Historias de Usuario (HU), se recopilan en el Product Backlog.
Roles Clave en Scrum
2.1 Product Owner
El Product Owner representa a los usuarios y clientes, asegurando que las características correctas se incluyan en el Product Backlog. Tiene la autoridad para tomar decisiones sobre el producto y su visión es fundamental para el éxito del proyecto. Debe ser capaz de identificar y resolver problemas que impidan el progreso.
2.2 Scrum Master
El Scrum Master facilita el proceso del proyecto, garantizando que el equipo cuente con las herramientas necesarias para realizar sus tareas. Organiza las reuniones y la planificación de la liberación del producto.
Planificación de la Liberación (Release Backlog)
Para la planificación de la liberación, se identifican las HU que se incluirán en cada release. El equipo prioriza las HU y estima el tiempo necesario para completarlas. Las historias grandes se dividen en tareas más pequeñas para facilitar su gestión. La suma de las estimaciones de tiempo determina la duración total del release.
Sprints
Los sprints son ciclos cortos de desarrollo que permiten verificar si la implementación de las HU se ajusta al tiempo estimado. La duración del sprint debe ser proporcional a la del Release Backlog. Al finalizar cada sprint, las características deben estar 100% terminadas y probadas.
Burndown Chart
El Burndown Chart muestra el progreso del trabajo y lo que falta para completarlo. El eje vertical representa el trabajo restante (que tiende a cero) y el eje horizontal representa el tiempo.
Daily Scrum
La reunión diaria (Daily Scrum o Sprint Review) es esencial para que los miembros del equipo compartan los obstáculos encontrados y busquen soluciones. Se recomienda la participación del cliente en estas reuniones.
3. Manifiesto Ágil
El Manifiesto Ágil define los valores fundamentales de las metodologías ágiles:
- Software funcionando sobre documentación exhaustiva: Se prioriza un software funcional sobre una documentación completa.
- Individuos e interacciones sobre procesos y herramientas: Se valora la sinergia del equipo por encima de las herramientas y procesos.
- Respuesta al cambio sobre seguir un plan: Se adapta al cambio en lugar de seguir un plan rígido.
- Colaboración con el cliente sobre negociación contractual: El cliente se considera un colaborador y parte del equipo.
Proceso Scrum
El proceso Scrum se inicia con una reunión donde se definen las características principales del producto. El Product Owner, con la autoridad otorgada por la organización, lidera este proceso.
Eventos Scrum
- Sprint Planning:
- Refinamiento: Se detallan las características del producto para que sean claras para el equipo.
- Tasking: Se dividen las tareas en unidades más pequeñas.
El Sprint Planning genera el Sprint Backlog, que define las tareas a realizar durante el sprint.
Incremento de Producto
El incremento de producto es la suma del desarrollo previo más el trabajo realizado durante el sprint.
Sprint Retrospective
La Sprint Retrospective evalúa el desempeño del equipo, identificando las áreas de mejora.
Refinamiento
El refinamiento es un proceso continuo de revisión y mejora de las características del producto.
4. Mantenimiento de Software
1. Necesidad de Cambio en el Software
Un software debe evolucionar o se volverá obsoleto. Las nuevas expectativas de los usuarios y los cambios en el entorno empresarial generan nuevos requerimientos.
2. Leyes de Lehman
Las leyes de Lehman pueden no ser aplicables cuando los requerimientos de un sistema no varían o cuando las modificaciones no afectan el valor del negocio.
3. Análisis del Impacto del Cambio
El análisis del impacto del cambio implica:
- Definir los tipos de cambio.
- Identificar las acciones críticas.
- Identificar el impacto de las causas.
- Elaborar un informe.
- Identificar los recursos necesarios.
4. Configuración de un Programa para Analizar el Mantenimiento
Para analizar el proceso de mantenimiento, se deben:
- Definir los requerimientos de la empresa.
- Implementar el sistema.
- Adaptar el sistema a los cambios en las reglas de negocio.
- Considerar el entorno en el que opera el sistema.
5. Tipos de Mantenimiento de Software
- Reparación de fallos: Corrección de errores en el código, diseño y componentes del programa.
- Adaptación ambiental: Adaptación del software a cambios en el hardware o la plataforma operativa.
- Adición de funcionalidad: Incorporación de nuevas funcionalidades en respuesta a cambios en la organización o el entorno empresarial.
6. Factores que Afectan los Costos de Reingeniería
- Reestructuración automatizada del programa.
- Reestructuración del programa y datos.
- Conversión automatizada del código fuente.
- Reestructuración automatizada con cambios manuales.
- Reestructuración con cambios arquitectónicos.
7. Circunstancias para Desechar un Sistema
Un sistema puede desecharse cuando no sea capaz de realizar operaciones efectivas para los procesos empresariales. Esto suele ocurrir cuando los procesos han cambiado desde la instalación del sistema y el sistema heredado ya no los soporta.
8. Opciones Estratégicas para la Evolución del Software
Las opciones estratégicas para la evolución del software incluyen:
- Desechar completamente el sistema.
- Mantener el sistema sin cambios y continuar con el mantenimiento regular.
- Someter el sistema a reingeniería para mejorar su mantenibilidad.
- Sustituir todo o parte del sistema con un nuevo sistema.
La decisión de sustituir completamente un sistema se toma cuando éste ya no satisface las necesidades del negocio o cuando los costos de mantenimiento son excesivos.