Inevitable Evolución del Software
La Primera Ley de Lehman
La primera ley establece que el mantenimiento del sistema es un proceso inevitable. A medida que cambia el entorno del sistema, surgen nuevas necesidades y el sistema debe ser modificado. Cuando el sistema modificado es introducido de nuevo en el medio ambiente, los cambios ambientales ocurren más y, por lo tanto, el ciclo reinicia el proceso de evolución.
La Segunda Ley de Lehman
La segunda ley establece que cuando el sistema se cambia, su estructura se degrada. La única manera de evitar esto es invertir en el mantenimiento preventivo en el que se emplean horas en la mejora de la estructura del software sin necesidad de añadir nuevas características. Obviamente, esto implicaría costos adicionales a los necesarios para implementar los cambios en el sistema.
La Tercera Ley de Lehman
La tercera ley de Lehman sugiere que los sistemas grandes tienen su propia dinámica que se define en las primeras etapas del proceso de desarrollo. Esto determina las tendencias del sistema y limita el número de cambios posibles. Lehman y Belady sugieren que esta ley es una consecuencia de factores estructurales que influyen y limitan los cambios del sistema, así como los factores organizativos que afectan a la evolución del sistema.
Tipos de Mantenimiento de Software
El mantenimiento de software se puede clasificar en tres categorías principales:
- Correctivo: Reparar los defectos de software.
- Adaptativo: Adaptar el software a un entorno operativo diferente.
- Evolutivo: Agregar funcionalidad al sistema o modificarlo en respuesta a cambios en la organización o negocio.
Mantenimiento Correctivo
La corrección de errores de codificación es normalmente barata, los errores de diseño son más caros, y puede ser necesario rediseñar el sistema existente.
Mantenimiento Adaptativo
Este tipo de mantenimiento es necesario cuando algún aspecto del entorno del sistema, tales como hardware, la plataforma de sistema operativo u otro software de soporte, cambia. El sistema de aplicación debe ser modificado para hacer frente a estos cambios del medio ambiente.
Mantenimiento Evolutivo
Este tipo de mantenimiento se requiere cuando los requisitos del sistema cambian en respuesta a cambios en la organización o negocio. La escala de los cambios necesarios para que el software es mucho mayor que en otros tipos de mantenimiento.
Pronóstico de Solicitudes de Cambio
Los gerentes odian las sorpresas, especialmente si se traducen en altos costos inesperados. Las previsiones se refieren a:
- Si un cambio de sistema debe ser aceptado, que depende, en cierta medida, de la facilidad de mantenimiento de los componentes del sistema afectados por este cambio.
- La implementación del sistema de cambios en su estructura tiende a degradarse, lo que reduce la facilidad de su mantenimiento.
- Los costos de mantenimiento dependen del número de cambios y los costos para implementar los cambios dependen de la capacidad de mantenimiento de los componentes del sistema.
Predecir el número de solicitudes de cambio de un sistema requiere un entendimiento de la relación entre el sistema y su ambiente externo. Para ello se debe evaluar:
- El número y la complejidad de las interfaces del sistema. Cuanto mayor sea el número de interfaces y la más compleja de las demandas, más probable es que haya solicitudes de cambios.
- El número de requisitos inherentemente inestables. Los requisitos que reflejan las políticas y procedimientos organizativos son probablemente más volátiles que los requisitos basados en las características estables de la zona.
- Procesos de negocio en el que se utiliza el sistema. A medida que los procesos de negocio evolucionan, generan las solicitudes de cambio. Cuantos más procesos de negocio interactúen con el sistema, más demandas de cambios habrá.
Métricas para Evaluar la Facilidad de Mantenimiento
Ejemplos de métricas de procesos que se pueden utilizar para evaluar la facilidad de mantenimiento son:
- Número de solicitudes de mantenimiento correctivo. Un incremento en el número de informes de error puede indicar que más errores se están introduciendo en el programa de reparación durante el proceso de mantenimiento, lo que puede indicar una disminución de la capacidad de mantenimiento.
- Promedio de tiempo necesario y deseado para el análisis de los impactos. Esto refleja el número de los componentes afectados por la solicitud de cambio. Si este tiempo aumenta, cada vez más componentes están siendo afectados y el mantenimiento está disminuyendo.
- Media hora de poner en práctica una solicitud de cambio. No es igual al tiempo para el análisis de los impactos, aunque existe una correlación. Esta cantidad de tiempo es necesaria para cambiar realmente el sistema y su documentación después de la evaluación de los componentes que se ven afectadas. Un aumento en el tiempo requerido para implementar un cambio indica una disminución de la capacidad de mantenimiento.
- Número de solicitudes pendientes de cambio. Un aumento de ese número a través del tiempo puede indicar una disminución de la capacidad de mantenimiento.
Cambios Urgentes en el Sistema
Las solicitudes de cambios suelen estar relacionados con problemas del sistema que deben ser abordados con urgencia. Estos cambios urgentes pueden surgir por tres razones:
- Hubo un grave defecto del sistema que debe ser reparado para permitir el funcionamiento normal continuo.
- Efectos de los cambios inesperados en el entorno del sistema operativo que interrumpen el funcionamiento normal.
- Cambios imprevistos en la empresa que utiliza el sistema en una situación de emergencia causada por los nuevos competidores o la introducción de nueva legislación.
Reingeniería de Software
La reingeniería de un sistema de software tiene dos ventajas principales sobre los enfoques más radicales de la evolución del sistema:
- Riesgo reducido: Existe un alto riesgo en el nuevo desarrollo de un software de negocio crítico. Los errores pueden ser cometidos en las especificaciones del sistema o puede haber problemas de desarrollo. Retrasos en la introducción del nuevo software puede significar la pérdida de negocio y resultar en costos adicionales.
- Reducción de los costos: El costo de la reingeniería es significativamente menor que el costo de desarrollar un nuevo software.
Actividades de la Reingeniería
- Conversión del código fuente: El programa se convierte de un lenguaje de programación antiguo a una versión más moderna del mismo lenguaje o a un lenguaje diferente.
- Técnicas de ingeniería inversa: El programa se analiza y se extrae la información del mismo. Esto ayuda a documentar su organización y funcionalidad.
- Mejora de la estructura del programa: La estructura de control del programa es analizada y modificada para facilitar su lectura y comprensión.
- Modularización de programas: Las partes relacionadas del programa se agrupan y, en su caso, los despidos son eliminados. En algunos casos, esta etapa puede implicar transformaciones de la arquitectura en la que una centralizada, planificada para un solo equipo, se ha modificado para funcionar en una plataforma distribuida.
- Reingeniería de los datos: Los datos procesados se cambian para reflejar los cambios de programa.
Factores que Afectan los Costos de Reingeniería
- La calidad del software a reingenierizar: Cuanto más baja sea la calidad del software y su documentación asociada (si existe), mayores serán los costos de reingeniería.
- Las herramientas disponibles para apoyar la reingeniería: En general, no es adecuado en términos de costo re-ingenierizar un sistema de software, a menos que utilice las herramientas CASE para automatizar la mayoría de los cambios.
- Extensión de la conversión de datos: Si la reingeniería requiere grandes volúmenes de datos a convertir, el proceso incrementará el costo significativamente.
- La disponibilidad de personal calificado: Si el personal responsable de mantener el sistema puede estar involucrado en el proceso de reingeniería, los costes aumentarán debido a que los ingenieros de sistemas responsables de reingeniería deben emplear mucho tiempo para entender el sistema.
La principal desventaja de la reingeniería de software es que hay limitaciones prácticas en la medida en que un sistema puede ser mejorado.
Estrategias para Sistemas Heredados
Las organizaciones con un presupuesto limitado para mantener y mejorar sus sistemas heredados deben decidir cómo obtener el mejor retorno de su inversión. Hay cuatro opciones de estrategia:
- Eliminar el sistema por completo: Esta opción se debe elegir cuando el sistema no está contribuyendo más eficazmente con los procesos de negocio.
- Dejar el sistema sin cambios y continuar con el mantenimiento regular: Esta opción se debe elegir cuando el sistema sigue siendo necesario, pero es muy estable, y los usuarios del sistema tienen relativamente pocas solicitudes para el cambio.
- Re-ingenierizar el sistema para mejorar su mantenimiento: Esta opción se debe elegir cuando la calidad del sistema se degrada por cambios regulares y cuando estos cambios siguen siendo necesarios.
- Reemplazar la totalidad o parte del sistema por un nuevo sistema: Esta opción debe ser elegida cuando otros factores tales como un nuevo hardware, hacen que sea imposible que el antiguo sistema pueda seguir operando o cuando los sistemas comerciales permiten un nuevo sistema se desarrolla a un costo razonable.
Evaluación de Sistemas Heredados
Agregados del Sistema
- De baja calidad, bajo valor de mercado: El mantenimiento de estos sistemas en operación será costoso y la tasa de retorno para el negocio será muy pequeña. Estos sistemas deben ser desechados.
- De baja calidad, alto valor de mercado: Estos sistemas contribuyen significativamente a la compañía y no pueden ser descartados. Sin embargo, la baja calidad significa que es muy caro mantenerlos. Estos sistemas tienen que sufrir reingeniería para mejorar su calidad o ser reemplazados si un sistema comercial adecuado está disponible.
- De alta calidad y bajo valor de mercado: Estos son los sistemas que no contribuyen a la empresa, pero su mantenimiento no es costoso. No vale la pena su sustitución, por lo que el mantenimiento normal puede continuar siempre y cuando no sea necesario modificar el hardware y el sistema esté en funcionamiento. Si los cambios son necesarios y costosos, los sistemas deben ser desechados.
- De alta calidad, alto valor de mercado: Estos sistemas deben mantenerse en funcionamiento, pero su calidad significa que usted no debe invertir en conversión o sustitución. La sustitución normal puede proceder.
Evaluación del Valor de Mercado
Para evaluar el valor de mercado de un sistema, es necesario identificar los actores del sistema como los usuarios finales y sus directivos, y formular una serie de preguntas sobre el sistema. Hay cuatro preguntas básicas que deben ser discutidas:
- El uso del sistema: Si los sistemas se utilizan de vez en cuando o por un número reducido de personas, pueden tener un bajo valor de mercado. Un sistema heredado puede haber sido desarrollado para satisfacer una necesidad de negocio que ha cambiado o que ahora se pueden satisfacer de manera más eficiente en otros aspectos.
- Procesos de apoyo al mercado: Cuando se introduce un sistema, los procesos pueden diseñarse para aprovechar este sistema de mercado. Sin embargo, los cambios en estos procesos pueden ser imposibles, porque el sistema de legado no puede ser adaptado. Por lo tanto, un sistema puede tener un valor bajo en el mercado, ya que impide la introducción de nuevos procesos.
- Confiabilidad del sistema: La fiabilidad del sistema no es sólo un problema técnico, sino también un problema de negocios. Si un sistema es fiable y los problemas afectan directamente a los clientes o requieren que las personas se desvíen de sus tareas para resolver estos problemas, el sistema tiene bajo valor de mercado.
- Las salidas del sistema: La cuestión fundamental aquí es la importancia de las salidas del sistema para el buen funcionamiento de la empresa. Si la empresa se basa en estos resultados, el sistema tiene un alto valor de mercado. Por otro lado, si estos resultados se pueden generar fácilmente de alguna otra manera o si el sistema genera las salidas utilizadas raramente, su valor de mercado puede ser bajo.
Evaluación de la Calidad Técnica
Para evaluar la calidad técnica de un sistema de aplicación, se debe evaluar varios factores, principalmente relacionados con la fiabilidad del sistema, la dificultad de mantenimiento del sistema y la documentación del sistema. Usted puede también recoger datos cuantitativos que le ayudará a juzgar la calidad del sistema. Algunos ejemplos de datos cuantitativos que pueden ser recogidos son los siguientes:
- El número de solicitudes de cambio en el sistema: Los cambios tienden a corromper la estructura del sistema y a realizar los cambios más difíciles. Cuanto mayor sea este valor, menor será la calidad del sistema.
- El número de interfaces de usuario: Este es un factor importante en los sistemas basados en formas, cada forma puede ser considerada como una interfaz independiente con el usuario. Cuantas más interfaces, mayor será la probabilidad de que haya inconsistencias y redundancias.
- El volumen de datos utilizados por el sistema: Cuanto mayor sea el volumen de datos (número de archivos, el tamaño de la base de datos, etc.), el sistema será más complejo.
Aunque estos datos son a menudo útiles, proceder a su recogida puede ser muy costoso y poco práctico por lo tanto. Además, no hay valores absolutos que se utilizarán. La edad y el tamaño del sistema debe ser tenido en cuenta en los juicios de calidad en base a estas mediciones.