Evolución del software

La evolución del software es el desarrollo continuo de un software después de su lanzamiento inicial para abordar los requisitos cambiantes de las partes interesadas y/o del mercado. La evolución del software es importante porque las organizaciones invierten grandes cantidades de dinero en su software y dependen completamente de él. La evolución del software ayuda al software a adaptarse a los requisitos cambiantes de las empresas, corregir defectos e integrarse con otros sistemas cambiantes en un entorno de sistemas de software.

Introducción general

Fred Brooks , en su libro clave The Mythical Man-Month , ^[1] afirma que más del 90% de los costos de un sistema típico surgen en la fase de mantenimiento, y que cualquier pieza de software exitosa inevitablemente necesitará mantenimiento.

De hecho, los métodos ágiles surgen de actividades similares al mantenimiento en y alrededor de tecnologías basadas en la web, donde la mayor parte de la capacidad proviene de marcos y estándares. ^{[ cita requerida ]}

El mantenimiento del software se ocupa de la corrección de errores y mejoras menores, mientras que la evolución del software se centra en la adaptación y la migración .

Las tecnologías de software seguirán desarrollándose. Estos cambios requerirán la creación y justificación de nuevas leyes y teorías. Algunos modelos también requerirán aspectos adicionales en el desarrollo de programas futuros. Las innovaciones y mejoras aumentan inesperadamente el desarrollo de software. Los problemas de mantenimiento probablemente también cambiarán para adaptarse a la evolución del software futuro. Los procesos de software están evolucionando en sí mismos; después de pasar por aprendizaje y refinamientos, siempre mejoran su eficiencia y eficacia. ^[2]

Conceptos básicos

La necesidad de evolución del software proviene del hecho de que nadie es capaz de predecir a priori cómo evolucionarán los requisitos del usuario . ^[3] En otras palabras, los sistemas existentes nunca están completos y continúan evolucionando. ^[4] A medida que evolucionan, la complejidad de los sistemas crecerá a menos que haya una mejor solución disponible para resolver estos problemas. Los principales objetivos de la evolución del software son asegurar la relevancia funcional, la confiabilidad y la flexibilidad del sistema. La evolución del software puede ser completamente manual (basada en cambios realizados por ingenieros de software), parcialmente automatizada (por ejemplo, utilizando herramientas de refactorización) o completamente automatizada.

La evolución del software se ha visto muy afectada por Internet:

• El rápido crecimiento de la World Wide Web y de los recursos de Internet facilita que los usuarios e ingenieros encuentren información relacionada.

• El desarrollo de código abierto, donde cualquiera puede descargar los códigos fuente y, por lo tanto, modificarlos, ha permitido una evolución rápida y paralela (a través de bifurcaciones).

Tipos de mantenimiento de software

EB Swanson identificó inicialmente tres categorías de mantenimiento: correctivo, adaptativo y perfectivo. Posteriormente, Lientz y Swanson (1980) catalogaron cuatro categorías de software. ^[5] Estas categorías se han actualizado y normalizado internacionalmente en la norma ISO/IEC 14764:2006: ^[6]

• Mantenimiento correctivo : Modificación reactiva de un producto de software realizada después de la entrega para corregir problemas descubiertos;
• 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 perfectivo : Modificación de un producto de software después de su entrega para mejorar el rendimiento o la capacidad de mantenimiento;
• Mantenimiento preventivo : Modificación de un producto de software después de su entrega para detectar y corregir fallas latentes en el producto de software antes de que se conviertan en fallas efectivas.

Todo lo anterior ocurre cuando existe una necesidad conocida de cambio.

Aunque estas categorías fueron complementadas por muchos autores como Warren et al. (1999) ^[7] y Chapin (2001), ^[8] la norma internacional ISO/IEC 14764:2006 ha mantenido las cuatro categorías básicas.

Más recientemente, la descripción del mantenimiento y evolución del software se ha realizado utilizando ontologías ( Kitchenham et al. (1999), ^[9] Deridder (2002), ^[10] Vizcaíno (2003), ^[11] Dias (2003), ^[12] y Ruiz (2004) ^[13] ), que enriquecen la descripción de las múltiples actividades de evolución.

Modelo de escenario

Las tendencias y prácticas actuales se proyectan hacia el futuro utilizando un nuevo modelo de evolución de software llamado modelo por etapas. ^[14] El modelo por etapas se introdujo para reemplazar el análisis convencional, que es menos adecuado para el desarrollo de software moderno que cambia rápidamente debido a sus dificultades de contribución en la evolución del software. Hay cinco etapas distintas que contribuyen al modelo por etapas simple (desarrollo inicial, evolución, mantenimiento, eliminación gradual y cierre).

• Según KHBennett y VT Rajlich, ^[14] la contribución clave es separar la fase de "mantenimiento" en una etapa de evolución seguida de etapas de servicio y eliminación gradual. La primera versión del sistema de software que carece de algunas características se desarrollará durante el desarrollo inicial o también conocido como etapa alfa. ^[14] Sin embargo, la arquitectura que ya se posee durante esta etapa traerá consigo cambios o modificaciones futuras. La mayoría de las referencias en esta etapa se basarán en escenarios o estudios de casos. El conocimiento se ha definido como otro resultado importante del desarrollo inicial. Dicho conocimiento incluye el conocimiento del dominio de la aplicación, los requisitos del usuario, las reglas comerciales, las políticas, las soluciones, el algoritmo, etc. El conocimiento también parece ser el factor importante para la fase posterior de evolución.
• Una vez que la etapa anterior se completó con éxito (y debe completarse con éxito antes de ingresar a la siguiente etapa), la siguiente etapa sería la evolución. Los usuarios tienden a cambiar sus requisitos, así como también prefieren ver algunas mejoras o cambios. Debido a este factor, la industria del software se enfrenta a los desafíos de un entorno de cambios rápidos. Por lo tanto, el objetivo de la evolución es adaptar la aplicación a los requisitos de los usuarios y al entorno operativo en constante cambio. ^[14] Durante la etapa anterior, la primera versión de la aplicación creada podría contener muchos fallos, y esos fallos se solucionarán durante la etapa de evolución en función de requisitos más específicos y precisos debido al estudio de caso o los escenarios.
• El software evolucionará continuamente hasta que ya no sea evolucionable y luego entrará en la etapa de mantenimiento (también conocida como madurez del software). Durante esta etapa, solo se realizarán cambios menores.
• La siguiente etapa es la de descontinuación, ya no hay más servicios disponibles para ese software en particular. Sin embargo, el software aún se encuentra en producción.
• Por último, el cierre. Se desconecta o se interrumpe el uso del software ^[14] y se orienta a los usuarios hacia un reemplazo. ^[14]

Leyes de la evolución del software de Lehman

El profesor Meir M. Lehman , que trabajó en el Imperial College de Londres entre 1972 y 2002, y sus colegas han identificado un conjunto de comportamientos en la evolución del software propietario. Estos comportamientos (u observaciones) se conocen como las Leyes de Lehman. Se refiere a los sistemas de tipo E como aquellos que están escritos para realizar alguna actividad del mundo real. El comportamiento de dichos sistemas está estrechamente vinculado al entorno en el que se ejecutan, y un sistema de este tipo necesita adaptarse a los distintos requisitos y circunstancias de ese entorno. Las ocho leyes son:

1. (1974) “Cambio continuo”: un sistema tipo E debe adaptarse continuamente o se vuelve progresivamente menos satisfactorio ^[15]
2. (1974) “Complejidad creciente”: a medida que evoluciona un sistema de tipo E, su complejidad aumenta a menos que se realice trabajo para mantenerla o reducirla ^[15]
3. (1980) "Autorregulación": los procesos de evolución de sistemas de tipo E se autorregulan con una distribución de medidas de productos y procesos cercana a lo normal ^[15]
4. (1978) "Conservación de la estabilidad organizacional (tasa de trabajo invariante)": la tasa de actividad global efectiva promedio en un sistema de tipo E en evolución es invariante durante la vida útil del producto ^[15]
5. (1978) “Conservación de la familiaridad”: a medida que evoluciona un sistema de tipo E, todos los asociados con él (desarrolladores, personal de ventas y usuarios, por ejemplo) deben mantener el dominio de su contenido y comportamiento para lograr una evolución satisfactoria. El crecimiento excesivo disminuye ese dominio. Por lo tanto, el crecimiento incremental promedio permanece invariable a medida que evoluciona el sistema. ^[15]
6. (1991) "Crecimiento continuo": el contenido funcional de un sistema tipo E debe aumentarse continuamente para mantener la satisfacción del usuario durante su vida útil.
7. (1996) "Calidad en declive": la calidad de un sistema tipo E parecerá estar en declive a menos que se mantenga rigurosamente y se adapte a los cambios del entorno operativo.
8. (1996) "Sistema de retroalimentación" (establecido por primera vez en 1974, formalizado como ley en 1996) — Los procesos de evolución de tipo E constituyen sistemas de retroalimentación de múltiples niveles, múltiples bucles y múltiples agentes y deben ser tratados como tales para lograr una mejora significativa sobre cualquier base razonable ^[16]

Vale la pena mencionar que varios investigadores han estudiado la aplicabilidad de todas estas leyes para todos los tipos de sistemas de software. Por ejemplo, véase una presentación de Nanjangud C Narendra ^[17] donde describe un estudio de caso de un proyecto ágil empresarial a la luz de las leyes de evolución del software de Lehman. Algunas observaciones empíricas provenientes del estudio del desarrollo de software de código abierto parecen desafiar algunas de las leyes ^{[ vago ] [ cita requerida ]} .

Las leyes predicen que la necesidad de un cambio funcional en un sistema de software es inevitable y no una consecuencia de un análisis incompleto o incorrecto de los requisitos o de una mala programación. Afirman que existen límites a lo que un equipo de desarrollo de software puede lograr en términos de implementar cambios y nuevas funcionalidades de manera segura.

Se han desarrollado modelos de madurez específicos para la evolución del software para mejorar los procesos y ayudar a garantizar el rejuvenecimiento continuo del software a medida que evoluciona iterativamente ^{[ cita requerida ]} .

El "proceso global" que realizan las distintas partes interesadas (por ejemplo, los desarrolladores, los usuarios y sus administradores) tiene muchos bucles de retroalimentación. La velocidad de evolución es una función de la estructura del bucle de retroalimentación y otras características del sistema global. Las técnicas de simulación de procesos, como la dinámica de sistemas, pueden ser útiles para comprender y gestionar este tipo de proceso global.

No es probable que la evolución del software sea darwiniana , lamarckiana o baldwiniana , sino un fenómeno importante en sí mismo. Dada la creciente dependencia del software en todos los niveles de la sociedad y la economía, la evolución exitosa del software se está volviendo cada vez más crítica. Este es un tema de investigación importante que no ha recibido mucha atención.

La evolución del software, debido a su rápido avance en comparación con otras entidades creadas por el hombre, fue vista por Lehman como la "mosca de la fruta" del estudio de la evolución de los sistemas artificiales.

Véase también

• Entropía del software
• Meir M. Lehman
• Evolución darwiniana
• Evolución lamarckiana
• Evolución baldwiniana
• Revista de software: evolución y procesos

Herramientas disponibles

• LibVCS4j Una biblioteca Java que permite que las herramientas existentes analicen la evolución de los sistemas de software al proporcionar una API común para diferentes sistemas de control de versiones y rastreadores de problemas.

Referencias

1. Fred Brooks , El mes mítico del hombre . Addison-Wesley , 1975 y 1995. ISBN 0-201-00650-2 y ISBN  0-201-83595-9 .
2. aeddy; ref: Comprender la evolución del software de código abierto Walt Scacchi Institute for Software Research
3. Bennett, KH; Rajlich, VT; Mazrul, R. Mohamad (1995). "Sistema heredado: cómo afrontar el éxito". IEEE Software . págs. 19–23.
4. Trung Hung Vo (2007), Mantenimiento de software
5. Lientz, BP y Swanson, EB, Gestión del mantenimiento de software: un estudio sobre el mantenimiento de software de aplicaciones informáticas en 487 organizaciones de procesamiento de datos . Addison-Wesley, Reading, MA, 1980. ISBN 0-201-04205-3 
6. ISO/IEC 14764:2006, 2006.
7. Paul Warren; Cornelia Boldyreff; Malcolm Munro (1999). "La evolución de los sitios web". Actas del Séptimo Taller Internacional sobre Comprensión de Programas . IEEE. págs. 178–185.
8. Ned Chapin; Joanne E Hale; Khaled Md Khan; Juan F Ramil; Wui-Gee Tan (2001). "Tipos de evolución y mantenimiento de software". Revista de mantenimiento y evolución de software: investigación y práctica . 13 (1): 3–30. doi :10.1002/smr.220.
9. Barbara Kitchenham ; Guilherme Travassos; Anneliese von Mayrhauser; Frank Niessink; Norman Schneidewind; Janice Singer; Shingo Takada; Risto Vehvilainen; Hongji Yang (1999). "Hacia una ontología del mantenimiento de software". Revista de mantenimiento de software: investigación y práctica . 11 (6): 365–389. doi : 10.1002/(SICI)1096-908X(199911/12)11:6<365::AID-SMR200>3.0.CO;2-W . hdl : 10945/55140 .
10. Dirk Deridder (2002). "Un enfoque orientado a conceptos para apoyar las actividades de mantenimiento y reutilización de software". Actas de la 5.ª Conferencia conjunta sobre ingeniería de software basada en el conocimiento .
11. Aurora Vizcaíno; Jesús Favela; Mario Piattini (2003). "Un sistema multiagente para la gestión del conocimiento en el mantenimiento de software". Knowledge-Based Intelligent Information and Engineering Systems . Springer. págs. 415–421.
12. Marcio Dias; Nicolás Anquetil; Káthia de Oliveira (2003). "Organización de los conocimientos utilizados en el mantenimiento del software". Revista de Informática Universal . 9 (7): 641–658.
13. Francisco Ruiz; Aurora Vizcaíno; Mario Piattini; Félix García (2004). "Una ontología para la gestión de proyectos de mantenimiento de software". Revista Internacional de Ingeniería de Software e Ingeniería del Conocimiento . 14 (3): 323–349. doi :10.1142/S0218194004001646. S2CID  15592498.
14. Bennett, Keith; Rajlich, Václav (1 de julio de 2000). "Un modelo por etapas para el ciclo de vida del software" (PDF) . Computer . 33 (7). IEEE Computer Society: 66–71. doi :10.1109/2.869374. S2CID  7547412 . Consultado el 23 de mayo de 2020 .{{cite journal}}: Mantenimiento CS1: fecha y año ( enlace )
15. Lehman, MM (1980). "Sobre la comprensión de las leyes, la evolución y la conservación en el ciclo de vida de los programas de gran tamaño". Revista de sistemas y software . 1 : 213–221. doi :10.1016/0164-1212(79)90022-0.
16. Leyes de la evolución del software de Lehman
17. Narendra, Nanjangud (29 de abril de 2011). "Evolución del software en el desarrollo ágil". InfoQ . Consultado el 19 de marzo de 2016 .

Lectura adicional

• Andrea Capiluppi, Jesús M.Gonzalez Barahona, Israel Herraiz, Gregorio Robles, Adaptando el "Modelo por etapas para la evolución del software" al software libre
• Mark C. Paulk, Una historia del modelo de madurez de capacidades del software