Mantenimiento del software

Modificación de un producto de software después de la entrega

Este artículo tiene varios problemas. Ayude a mejorarlo o discuta estos problemas en la página de discusión . ( Obtenga información sobre cómo y cuándo eliminar estos mensajes de plantilla ) Este artículo tiene un estilo de cita poco claro . Las referencias utilizadas pueden aclararse con un estilo diferente o coherente de citas y notas al pie . ( Septiembre de 2010 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla ) Este artículo necesita citas adicionales para su verificación . Por favor, ayuda a mejorar este artículo mediante la adición de citas de fuentes confiables . El material no obtenido puede ser cuestionado y eliminado. Buscar fuentes:  "Mantenimiento de software"  -  noticias  · periódicos  · libros  · académico  · JSTOR ( enero de 2015 ) ( Aprenda cómo y cuándo eliminar este mensaje de plantilla ) ( Aprenda cómo y cuándo eliminar este mensaje de plantilla )

Desarrollo de software
Actividades centrales Actividades principales Procesos Requisitos Diseño Ingenieria Construcción Pruebas Depuración Despliegue Mantenimiento
Paradigmas y modelos Ágil Sala limpia Incremental Creación de prototipos Espiral Modelo V Cascada
Metodologías y marcos TEA DevOps PADRE DSDM FDD IID Kanban Lean SD Menos MDD MSF PSP RAD RUP A salvo Melé SEMAT TSP Abrir HASTA XP
Disciplinas de apoyo Gestión de la configuración Documentación Aseguramiento de la calidad del software (SQA) Gestión de proyectos Experiencia de usuario
Practicas ATDD BDD CCO CI discos compactos DDD PÁGINAS SBE Ponerse de pie TDD
Instrumentos Compilador Depurador Perfilador Diseñador de GUI Modelado IDE Automatización de construcción Automatización de lanzamientos Infraestructura como código Pruebas
Estándares y cuerpos de conocimiento BABOK CMMI Estándares IEEE ISO 9001 Normas ISO / IEC PMBOK SWEBOK ITIL IREB
Glosarios Inteligencia artificial Ciencias de la Computación Ingeniería eléctrica y electrónica
Contornos Esquema del desarrollo de software
v t mi

El mantenimiento de software en la ingeniería de software es la modificación de un producto de software después de la entrega para corregir fallas, mejorar el rendimiento u otros atributos. ^[1]

Una percepción común del mantenimiento es que simplemente implica reparar defectos . Sin embargo, un estudio indicó que más del 80% del esfuerzo de mantenimiento se utiliza para acciones no correctivas. ^[2] Esta percepción se perpetúa cuando los usuarios envían informes de problemas que en realidad son mejoras de funcionalidad del sistema. ^{[ cita requerida ]} Estudios más recientes sitúan la proporción de corrección de errores más cerca del 21%. ^[3]

Historia

El mantenimiento del software y la evolución de los sistemas fue abordado por primera vez por Meir M. Lehman en 1969. Durante un período de veinte años, su investigación condujo a la formulación de las leyes de Lehman (Lehman 1997). Los hallazgos clave de su investigación concluyen que el mantenimiento es realmente un desarrollo evolutivo y que las decisiones de mantenimiento se basan en la comprensión de lo que sucede con los sistemas (y el software) a lo largo del tiempo. Lehman demostró que los sistemas continúan evolucionando con el tiempo. A medida que evolucionan, se vuelven más complejos a menos que se tome alguna acción, como la refactorización del código, para reducir la complejidad. A fines de la década de 1970, un estudio de encuesta famoso y ampliamente citado por Lientz y Swanson, expuso la fracción muy alta de los costos del ciclo de vida que se gastaban en mantenimiento.

La encuesta mostró que alrededor del 75% del esfuerzo de mantenimiento se realizó en los dos primeros tipos, y la corrección de errores consumió alrededor del 21%. Muchos estudios posteriores sugieren una magnitud de problema similar. Los estudios demuestran que la contribución de los usuarios finales es crucial durante la recopilación y el análisis de datos de nuevos requisitos. Esta es la principal causa de cualquier problema durante la evolución y el mantenimiento del software. El mantenimiento del software es importante porque consume una gran parte de los costos generales del ciclo de vida y también la incapacidad de cambiar el software de manera rápida y confiable significa que se pierden oportunidades comerciales.^{[4] [5] [6]}

Importancia del mantenimiento de software

Los problemas clave del mantenimiento del software son tanto de gestión como técnicos. Los problemas de gestión clave son: alineación con las prioridades del cliente, dotación de personal, qué organización realiza el mantenimiento, estimación de costos. Los problemas técnicos clave son: comprensión limitada, análisis de impacto , pruebas, medición de la capacidad de mantenimiento.

El mantenimiento de software es una actividad muy amplia que incluye corrección de errores, mejoras de capacidades, eliminación de capacidades obsoletas y optimización. Dado que el cambio es inevitable, se deben desarrollar mecanismos de evaluación, control y modificación.

Por lo tanto, cualquier trabajo realizado para cambiar el software después de que esté en funcionamiento se considera trabajo de mantenimiento. El propósito es preservar el valor del software a lo largo del tiempo. El valor se puede mejorar expandiendo la base de clientes, cumpliendo requisitos adicionales, volviéndose más fácil de usar, más eficiente y empleando tecnología más nueva. El mantenimiento puede durar 20 años, ^{[ cita requerida ]} mientras que el desarrollo puede ser de 1 a 2 años. ^{[ cita requerida ]}

Planificación de mantenimiento de software

Una parte integral del software es el de mantenimiento, que requiere la preparación de un plan de mantenimiento preciso durante el desarrollo del software. Debe especificar cómo los usuarios solicitarán modificaciones o informarán problemas. El presupuesto debe incluir estimaciones de recursos y costos. Se debe abordar una nueva decisión para el desarrollo de cada nueva característica del sistema y sus objetivos de calidad. El mantenimiento del software, que puede durar de 5 a 6 años (o incluso décadas) después del proceso de desarrollo, requiere un plan eficaz que pueda abordar el alcance del mantenimiento del software, la adaptación del proceso posterior a la entrega / implementación, la designación de quién proporcionará mantenimiento y una estimación de los costos del ciclo de vida.La selección de la aplicación adecuada de los estándares es una tarea desafiante desde la etapa inicial de la ingeniería de software que no ha adquirido una importancia definida por parte de las partes interesadas.

Procesos de mantenimiento de software

Esta sección describe los seis procesos de mantenimiento de software como:

1. El proceso de implementación contiene actividades de preparación y transición del software, como la concepción y creación del plan de mantenimiento; la preparación para manejar los problemas identificados durante el desarrollo; y el seguimiento de la gestión de la configuración del producto.
2. El proceso de análisis de problemas y modificaciones, que se ejecuta una vez que la aplicación pasa a ser responsabilidad del grupo de mantenimiento. El programador de mantenimiento debe analizar cada solicitud, confirmarla (reproduciendo la situación) y comprobar su vigencia, investigarla y proponer una solución, documentar la solicitud y la propuesta de solución, y finalmente, obtener todas las autorizaciones necesarias para aplicar las modificaciones.
3. El proceso considerando la implementación de la modificación en sí.
4. El proceso de aceptación de la modificación, mediante la confirmación del trabajo modificado con la persona que presentó la solicitud para asegurarse de que la modificación proporcionó una solución.
5. El proceso de migración ( migración de plataforma , por ejemplo) es excepcional y no forma parte de las tareas de mantenimiento diarias. Si el software debe trasladarse a otra plataforma sin ningún cambio en la funcionalidad, se utilizará este proceso y es probable que se asigne un equipo de proyecto de mantenimiento a esta tarea.
6. Finalmente, el último proceso de mantenimiento, también un evento que no ocurre a diario, es el retiro de una pieza de software.

Hay una serie de procesos, actividades y prácticas que son exclusivos de los mantenedores, por ejemplo:

• Transición: una secuencia controlada y coordinada de actividades durante las cuales un sistema se transfiere progresivamente del desarrollador al mantenedor.
• Acuerdos de nivel de servicio (SLA) y contratos de mantenimiento especializados (específicos del dominio) negociados por los mantenedores
• Mesa de ayuda para solicitudes de modificación e informes de problemas: un proceso de manejo de problemas utilizado por los encargados de mantenimiento para priorizar, documentar y enrutar las solicitudes que reciben

Categorías de mantenimiento de software

EB Swanson identificó inicialmente tres categorías de mantenimiento: correctivo, adaptativo y perfectivo. ^[7] El estándar IEEE 1219 fue reemplazado en junio de 2010 por P14764 . ^[8] Estos han sido actualizados desde entonces e ISO / IEC 14764 presenta:

• Mantenimiento correctivo : modificación reactiva de un producto de software realizada después de la entrega para corregir problemas descubiertos. El mantenimiento correctivo se puede automatizar con la corrección automática de errores .
• Mantenimiento adaptativo: modificación de un producto de software realizada después de la entrega para mantener un producto de software utilizable en un entorno modificado o cambiante.
• Mantenimiento perfecto: modificación de un producto de software después de la entrega para mejorar el rendimiento o la capacidad de mantenimiento .
• Mantenimiento preventivo : Modificación de un producto de software después de la entrega para detectar y corregir fallas latentes en el producto de software antes de que se conviertan en fallas efectivas.

También existe una noción de mantenimiento previo a la entrega / lanzamiento, que es todo lo bueno que hace para reducir el costo total de propiedad del software. Cosas como el cumplimiento de los estándares de codificación que incluyen objetivos de mantenimiento del software. La gestión de acoplamiento y cohesión del software. El logro de los objetivos de compatibilidad del software (SAE JA1004, JA1005 y JA1006, por ejemplo). Algunas instituciones académicas ^{[ ¿quién? ]} están llevando a cabo investigaciones para cuantificar el costo del mantenimiento continuo del software debido a la falta de recursos, como documentos de diseño y capacitación y recursos en comprensión del sistema / software (multiplique los costos por aproximadamente 1,5-2,0 cuando no haya datos de diseño disponibles).

Factores de mantenimiento

Impacto de los factores de ajuste clave en el mantenimiento (ordenados en orden de impacto positivo máximo)

Factores de mantenimiento	Gama Plus
Especialistas en mantenimiento	35%
Alta experiencia del personal	34%
Variables y datos basados ​​en tablas	33%
Baja complejidad del código base	32%
Y2K y motores de búsqueda especiales	30%
Herramientas de reestructuración de código	29%
Herramientas de reingeniería	27%
Lenguajes de programación de alto nivel	25%
Herramientas de ingeniería inversa	23%
Herramientas de análisis de complejidad	20%
Herramientas de seguimiento de defectos	20%
Especialistas en "actualización masiva" del año 2000	20%
Herramientas de control de cambios automatizadas	18%
Horas extras no pagadas	18%
Medidas de calidad	dieciséis%
Inspecciones formales del código base	15%
Bibliotecas de prueba de regresión	15%
Excelente tiempo de respuesta.	12%
Entrenamiento anual de> 10 días	12%
Alta experiencia gerencial	12%
Automatización del escritorio HELP	12%
Sin módulos propensos a errores	10%
Informe de defectos en línea	10%
Medidas de productividad	8%
Excelente facilidad de uso	7%
Medidas de satisfacción del usuario	5%
Alta moral del equipo	5%
Suma	503%

Los módulos propensos a errores no solo son problemáticos, sino que muchos otros factores también pueden degradar el rendimiento. Por ejemplo, un código espagueti muy complejo es bastante difícil de mantener de forma segura. Una situación muy común que a menudo degrada el rendimiento es la falta de herramientas de mantenimiento adecuadas, como software de seguimiento de defectos, software de gestión de cambios y software de biblioteca de pruebas. A continuación, describa algunos de los factores y el rango de impacto en el mantenimiento del software.

Impacto de los factores de ajuste clave en el mantenimiento (ordenados en orden de impacto negativo máximo)

Factores de mantenimiento	Rango menos
Módulos propensos a errores	-50%
Variables y datos incrustados	-45%
Inexperiencia del personal	-40%
Alta complejidad de código	-30%
Sin Y2K de motores de búsqueda especiales	-28%
Métodos de control de cambios manuales	-27%
Lenguajes de programación de bajo nivel	-25%
Sin herramientas de seguimiento de defectos	-24%
Sin especialistas en "actualizaciones masivas" del año 2000	-22%
Poca facilidad de uso	-18%
Sin mediciones de calidad	-18%
Sin especialistas en mantenimiento	-18%
Poco tiempo de respuesta	-dieciséis%
Sin inspecciones de código	-15%
Sin bibliotecas de prueba de regresión	-15%
Sin automatización de la mesa de ayuda	-15%
Sin informes de defectos en línea	-12%
Inexperiencia gerencial	-15%
Sin herramientas de reestructuración de código	-10%
Sin formación anual	-10%
Sin herramientas de reingeniería	-10%
Sin herramientas de ingeniería inversa	-10%
Sin herramientas de análisis de complejidad	-10%
Sin mediciones de productividad	-7%
Mala moral del equipo	-6%
Sin mediciones de satisfacción del usuario	-4%
Sin horas extra impagas	0%
Suma	-500%

^[9]

Deuda de mantenimiento

En un documento para la 27a Conferencia Internacional sobre Gestión de la Calidad del Software en 2019, ^[10] John Estdale introdujo el término "deuda de mantenimiento" para las necesidades de mantenimiento generadas por la dependencia de una implementación de factores externos de TI como bibliotecas, plataformas y herramientas, que se han convertido en caído en desuso. ^[11] La aplicación continúa ejecutándose y el departamento de TI olvida esta responsabilidad teórica, centrándose en requisitos y problemas más urgentes en otros lugares. Dicha deuda se acumula con el tiempo, consumiendo silenciosamente el valor del activo de software. Eventualmente sucede algo que hace que el cambio de sistema sea inevitable.

El propietario puede descubrir entonces que el sistema ya no se puede modificar; literalmente, no se puede mantener. De manera menos dramática, el mantenimiento puede llevar demasiado tiempo o costar demasiado para resolver el problema comercial, y se debe encontrar una solución alternativa. El software se ha estrellado repentinamente al valor de £ 0.

Estdale define "Deuda de mantenimiento" ^[11] como: la brecha entre el estado de implementación actual de una aplicación y el ideal, utilizando solo la funcionalidad de los componentes externos que se mantienen y respaldan en su totalidad. Esta deuda suele estar oculta o no reconocida. La capacidad de mantenimiento general de una aplicación depende de la posibilidad de obtener componentes de todo tipo de otros proveedores, incluidos:

• Herramientas de desarrollo: edición de código fuente, gestión de configuración, compilación y compilación
• Herramientas de prueba: selección de pruebas, ejecución / verificación / informes
• Plataformas para ejecutar lo anterior: hardware, sistema operativo y otros servicios
• Entorno de producción y cualquier instalación en espera / recuperación ante desastres, incluido el entorno de soporte en tiempo de ejecución del lenguaje del código fuente, y el ecosistema más amplio de programación de trabajos, transferencia de archivos, almacenamiento replicado, copia de seguridad y archivo, inicio de sesión único, etc.
• Paquetes adquiridos por separado, por ejemplo, DBMS, gráficos, comunicaciones, middleware
• Comprado en código fuente, bibliotecas de código objeto y otros servicios invocables
• Cualquier requisito que surja de otras aplicaciones que comparten el entorno de producción o que interactúan con la aplicación en cuestión.

y por supuesto

• La disponibilidad de habilidades relevantes, internamente o en el mercado.

La desaparición completa de un componente podría hacer que la aplicación no se pueda reconstruir o que sea inminentemente imposible de mantener.

Ver también

• Retiro de la aplicación
• Revista de mantenimiento y evolución de software: investigación y práctica
• Soporte a largo plazo
• Ingeniería de software basada en búsquedas
• Arqueología de software
• Mantenedor de software
• Desarrollo de software

Referencias

^[12]

1. "ISO / IEC 14764: 2006 Ingeniería de software - Procesos del ciclo de vida del software - Mantenimiento" . Iso.org. 2011-12-17 . Consultado el 2 de diciembre de 2013 .
2. Pigoski, Thomas M., 1997: Mantenimiento práctico de software: mejores prácticas para administrar su inversión en software. Pub de la computadora de Wiley. (Nueva York)
3. Eick, S., Graves, T., Karr, A., Marron, J. y Mockus, A. 2001. ¿Code Decay? Evaluación de la evidencia de los datos de gestión del cambio. Transacciones IEEE sobre ingeniería de software. 27 (1) 1-12.
4. Lientz B., Swanson E., 1980: Gestión de mantenimiento de software. Addison Wesley, Reading, MA
5. Lehman MM, 1980: Programa, ciclos de vida y las leyes de la evolución del software. En Actas de IEEE, 68, 9,1060-1076
6. Penny Grubb, Armstrong A. Takang, 2003: Mantenimiento de software: conceptos y práctica. Compañía Editorial Científica Mundial
7. "E. Burt Swanson, las dimensiones del mantenimiento. Actas de la segunda conferencia internacional sobre ingeniería de software, San Francisco, 1976, págs. 492 - 497" . Portal.acm.org. doi : 10.1145 / 359511.359522 . S2CID 14950091 . Consultado el 2 de diciembre de 2013 . 
8. Estado de 1219-1998 según los estándares IEEE
9. "La economía del mantenimiento de software en el siglo XXI" (PDF) . Archivado desde el original (PDF) el 19 de marzo de 2015 . Consultado el 2 de diciembre de 2013 .
10. Khan, O; Marchbank, P; Georgiadou, E; Linecar, P; Ross, M; Grapas, G (2019). Proc de Gestión de Calidad de Software XXVII: Experiencias e Iniciativas Internacionales en Gestión de Calidad de TI . Southampton: Universidad de Solent. ISBN 978-1-9996549-2-4.
11. Estdale, John. Retrasar el mantenimiento puede resultar fatal . en [11]. págs. 95-106.
12. Pigoski, Thomas. "Capítulo 6: Mantenimiento de software" (PDF) . SWEBOK . IEEE . Consultado el 5 de noviembre de 2012 .

Lectura adicional

• ISO / IEC 14764 IEEE Std 14764-2006 Ingeniería de software - Procesos del ciclo de vida del software - Mantenimiento . 2006. doi : 10.1109 / IEEESTD.2006.235774 . ISBN 0-7381-4960-8.
• Pigoski, Thomas M. (1996). Práctico mantenimiento de software . Nueva York: John Wiley & Sons. ISBN 978-0-471-17001-3.
• Pigoski, Thomas M. Descripción para la evolución y el mantenimiento de software (versión 0.5) . Área de conocimiento SWEBOK.
• April, Alain; Abran, Alain (2008). Gestión de mantenimiento de software . Nueva York: Wiley-IEEE. ISBN 978-0-470-14707-8.
• Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Mantenimiento de software: prácticas efectivas para entornos distribuidos geográficamente . Nueva Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
• Grubb, Penny; Takang, Armstrong (2003). Mantenimiento de software . Nueva Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
• Lehman, MM; Belady, LA (1985). Evolución del programa: procesos de cambio de software . Londres: Academic Press Inc. ISBN 0-12-442441-4.
• Page-Jones, Meilir (1980). La guía práctica para el diseño de sistemas estructurados . Nueva York: Yourdon Press. ISBN 0-917072-17-0.

Enlaces externos

• Revista de mantenimiento de software