Evolución del software

La evolución del software es el desarrollo continuo de una pieza de software después de su lanzamiento inicial para abordar los cambios en los requisitos 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 comerciales cambiantes, corregir defectos e integrarse con otros sistemas cambiantes en un entorno de sistema 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 será mantenida.

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

El mantenimiento del software aborda 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ían aspectos adicionales en el desarrollo de programas futuros. Las innovaciones y mejoras aumentan las formas inesperadas de desarrollo de software. Los temas de mantenimiento también probablemente cambiarían para adaptarse a la evolución del futuro software. Los procesos de software están evolucionando en sí mismos; después de pasar por aprendizajes y mejoras, siempre es necesario mejorar su eficiencia y eficacia. ^[2]

Conceptos básicos

La necesidad de evolución del software surge del hecho de que nadie es capaz de predecir a priori cómo evolucionarán los requisitos de los usuarios . ^[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 garantizar la relevancia funcional, la confiabilidad y la flexibilidad del sistema. La evolución del software puede ser totalmente manual (basada en cambios realizados por ingenieros de software), parcialmente automatizada (por ejemplo, utilizando herramientas de refactorización) o totalmente automatizada.

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

• El rápido crecimiento de la World Wide Web y los recursos de Internet facilita a los usuarios e ingenieros encontrar 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 las tres categorías de mantenimiento: correctivo, adaptativo y perfectivo. Lientz y Swanson (1980) catalogaron cuatro categorías de software. ^[5] Desde entonces, estos han sido actualizados y normalizados 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 la entrega para mejorar el rendimiento o la mantenibilidad;
• 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.

Todo lo anterior tiene lugar 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 mediante 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 la evolución.

modelo de escenario

Las tendencias y prácticas actuales se proyectan hacia adelante utilizando un nuevo modelo de evolución del 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 y está cambiando rápidamente debido a sus dificultades para contribuir en la evolución del software. Hay cinco etapas distintas que contribuyen en un 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 una etapa de servicio y una etapa de eliminación gradual. La primera versión del sistema de software al que le faltan algunas características se desarrollará durante el desarrollo inicial o también conocida como etapa alfa. ^[14] Sin embargo, la arquitectura que ya se ha poseído 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, los algoritmos, etc. El conocimiento también parece ser un factor importante para la fase posterior de la evolución.
• Una vez que la etapa anterior se completó con éxito (y debe completarse con éxito antes de pasar a la siguiente etapa), la siguiente etapa sería la evolución. Los usuarios tienden a cambiar sus requisitos y prefieren ver algunas mejoras o cambios. Debido a este factor, la industria del software se enfrenta a los desafíos de un entorno de rápidos cambios. Por lo tanto, el objetivo de la evolución es adaptar la aplicación a los requisitos del usuario y al entorno operativo en constante cambio. ^[14] Durante la etapa anterior, la primera versión de la aplicación creada puede contener muchas fallas, y esas fallas 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 escenarios.
• El software evolucionará continuamente hasta que ya no sea capaz de evolucionar y luego entrará en la etapa de servicio (también conocida como madurez del software). Durante esta etapa, sólo se realizarán cambios menores.
• En la siguiente etapa, que es la eliminación gradual, ya no hay más servicios disponibles para ese software en particular. Sin embargo, el software aún está en producción.
• Por último, cierre. El uso del software se desconecta o se interrumpe ^[14] y se dirige a los usuarios hacia un reemplazo. ^[14]

Leyes de Lehman sobre la evolución del software

El profesor Meir M. Lehman , que trabajó en el Imperial College de Londres de 1972 a 2002, y sus colegas han identificado una serie de comportamientos en la evolución del software propietario. Estos comportamientos (u observaciones) se conocen como 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á fuertemente vinculado al entorno en el que se ejecutan, y dicho sistema debe adaptarse a los diferentes requisitos y circunstancias de ese entorno. Las ocho leyes son:

1. (1974) "Cambio continuo": un sistema de 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 trabaje para mantenerla o reducirla ^[15]
3. (1980) "Autorregulación": los procesos de evolución del sistema tipo E se autorregulan con la distribución del producto y las medidas del proceso cercanas 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, los desarrolladores, el personal de ventas y los 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 tanto, el crecimiento incremental promedio permanece invariante 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 descenso": la calidad de un sistema tipo E parecerá estar disminuyendo 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 tratarse como tales para lograr una mejora significativa sobre cualquier sistema razonable. bases ^[16]

Vale la pena mencionar que varios investigadores han estudiado la aplicabilidad de todas estas leyes para todo tipo de sistemas de software. Por ejemplo, consulte una presentación de Nanjangud C Narendra ^[17] donde describe un estudio de caso de un proyecto empresarial ágil 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 ^{[ vagas ] [ cita necesaria ]} .

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 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 forma 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 de forma iterativa ^{[ cita necesaria ]} .

El "proceso global" que realizan las numerosas partes interesadas (por ejemplo, desarrolladores, usuarios, sus administradores) tiene muchos circuitos de retroalimentación. La velocidad de evolución es función de la estructura del circuito 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 resultar útiles para comprender y gestionar dichos procesos globales.

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 es cada vez más crítica. Este es un tema importante de investigación 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.

Ver también

• Entropía del software
• Meir Lehman
• evolución darwiniana
• evolución lamarckiana
• evolución baldwiniana
• Revista de software: evolución y proceso

Herramientas disponibles

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

Referencias

1. Fred Brooks , El mes del hombre mítico . Addison-Wesley , 1975 y 1995. ISBN 0-201-00650-2 y ISBN  0-201-83595-9 .
2. remolino; ref: Comprensión de la evolución del software de código abierto Instituto Walt Scacchi para la Investigación de Software
3. Bennett, KH; Rajlich, VT; Mazrul, R. Mohamad (1995). "Sistema heredado: afrontar el éxito". Software IEEE . 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, lectura MA, 1980. ISBN 0-201-04205-3 
6. ISO/IEC 14764:2006, 2006.
7. Pablo 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 del software y mantenimiento del software". Revista de mantenimiento y evolución del software: investigación y práctica . 13 (1): 3–30. doi :10.1002/smr.220.
9. Bárbara Kitchenham ; Guilherme Travassos; Anneliese von Mayrhauser; Frank Niessink; Norman Schneidewind; Janice cantante; Shingo Takada; Risto Vehvilainen; Hongji Yang (1999). "Hacia una ontología del mantenimiento del 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 respaldar las actividades de reutilización y mantenimiento de software". Actas de la quinta 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". Sistemas de ingeniería e información inteligentes basados ​​en el conocimiento . Saltador. 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 Ruíz; 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) . Computadora . 33 (7). Sociedad de Computación IEEE: 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 grandes". Revista de Sistemas y Software . 1 : 213–221. doi :10.1016/0164-1212(79)90022-0.
16. Leyes de 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 .

Otras lecturas

• 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 software del modelo de madurez de capacidad