Del modelo tradicional a los modelos de reutilización del ...

Puente de Hierro V1, n.1 20 de enero de 2021

1 / 10

Del modelo tradicional a los modelos de reutilización del Software para grandes

Sistemas de Defensa.

Francisco José López García [email protected]

Enero – 2021

Resumen

En este articulo se ofrece una somera visión de la historia de la Ingeniería del Software, centrándonos en los acontecimientos fundamentales que han forjado la actual configuración de esta disciplina. En el ámbito del Software aplicado a los grandes sistemas de defensa, se muestran las aproximaciones metodológicas establecidas desde el inicio y como los problemas encontrados han dado como resultado la aplicación de tecnologías orientadas a minimizar los costes, el tiempo para la puesta en servicio y aumentar la calidad. Se añaden dos ejemplos de éxito de la aplicación de la ingeniería de líneas de producto.

Breve reseña histórica. Ingeniería del Software

A Margaret Hamilton [1] se le atribuye la invención del termino “Ingeniería del Software” [2]; desde 1965 fue la responsable, junto con su equipo, del Software del ordenador del módulo de mando y del módulo lunar del Apolo XI y probablemente, la persona que evitó el fracaso de la primera misión que llevó un hombre a la luna. Universalmente famosa tras recibir una de las medallas presidenciales de la libertad de manos del presidente de los Estados unidos Barack Obama, luchó por la asimilación de la terminología empleada para el Software al mismo nivel que la que se empleaba para el hardware, durante los años que trabajó en la NASA

Pero quizás el espaldarazo al término “Ingeniería del Software” se realizó en las conferencias “NATO Software Engineering Conference” [3] (1968-1969). A estas conferencias asistieron expertos internacionales en Software donde acordaron y recomendaron técnicas y métodos que se tendrían que emplear en el desarrollo del Software.


2 / 10

Ya en dichas conferencias se trató el concepto de “crisis del software”, algo

llamativo para una ingeniería que acababa de nacer alrededor del concepto llamado Software acuñado por primera vez por John Turkey en 1952 [4].

La crisis del software se identificó con tres factores fundamentales: los sobrecostes, el incumplimiento de plazos y los fallos en la funcionalidad (calidad). Durante más de 20 años (1965-1985) la Ingeniería del Software se vio en la necesidad de madurar, se introducen los conceptos de programación modular, la programación estructurada, la invención del lenguaje Pascal, así como el Simula, lenguaje de programación orientado a objetos. Aparecen también conceptos como abstracción, ocultación y los modelos de entidad relación. Ed. Yourdon [5], Tom Demarco [6]– entre otros – desarrollaron los métodos de análisis y diseño estructurado.

Durante los 80, los problemas identificados para los grandes sistemas de defensa se pretendieron atajar con normas y estándares como la DOD-STD-2167 y el lenguaje ADA, promovidos por el Departamento de Defensa Americano (DOD). Durante esta época se establecen nuevas ideas como la orientación a objetos, la economía y las métricas aplicadas al Software, así como la nueva generación de lenguajes: C++, Java y el Visual Basic.

Internet vendría a revolucionar la década de los 90, una plataforma que permitirá la distribución de aplicaciones e información y que será el principio de un cambio tecnológico fundamental para la humanidad. Se consolidan los conceptos de herencia, reutilización y empleo de técnicas automatizadas de desarrollo Software.

A principios del siglo XXI, con la popularización del teléfono móvil, se consolidan los nuevos lenguajes de programación como JavaScript, Python, C++, C#, PHP. La programación pasa de ser monolítica y en los “mainframes” a la “nube” con micro-servicios y “APPs” y llega la filosofía de los “frameworks”. Dos acontecimientos importantes se pueden destacar de esta época: la explosión del Software libre (open source) y los métodos Ágiles.

En la última década esfuerzos como SWEBOK [7] y “The Systems Engineering Body of Knowledge” de INCOSE [8], tratan de sistematizar la ingeniería del Software. Esta nueva evolución tendrá más que ver con la Inteligencia Artificial, el “Big Data” y las redes neuronales.

Ilustración 1 Informes de las sesiones NATO Software Engineering Conference. [3]


3 / 10

Modelo clásico de desarrollo Software. El modelo en Cascada A Winston Royce se le atribuye la invención del modelo en cascada e inspiración de la norma 2167 del DOD. En el articulo escrito en 1970 “Managing the Development of Large Software Systems" Ilustración 2 [9], se puede encontrar la clásica representación del modelo en cascada:

En este modelo las actividades se descomponen linealmente en fases secuenciales, dependiendo cada fase de los productos y documentos de las fases anteriores.

Realmente el articulo de Royce es unos de los primeros alegatos al desarrollo incremental e iterativo proponiendo, en base a su experiencia, el desarrollo de un prototipo y añadiendo 5 pasos más al modelo tradicional: 1. Diseñar, 2. Documentar el diseño, 3. Hacerlo dos veces, 4. Planificar, controlar y monitorizar las pruebas, 5. Involucrar al cliente.

En 1988 el DOD publicó una actualización completa de la anterior norma, la DOD-STD-2167A “Defense System Software Development” [10], donde quedaron claramente identificados los conceptos tradicionales del modelo en

Ilustración 2 Pasos en el desarrollo de grandes programas Fuente: Managing the development of large software system, Winston W. Royce. [9]


4 / 10

cascada y la necesidad de un gran aporte documental relacionado con el desarrollo software.

Ilustración 3 Productos entregables, revisiones, auditorias y líneas base

Fuente: DoD-STD-2167A [10]

En 1994 fue reemplazada por la MIL-STD-498, que añadía el concepto de

adaptación y reutilización, e incluía la posibilidad de emplear métodos incrementales y/o evolutivos. Esta norma tuvo una vida efímera al ser desplazada tempranamente por nuevos estándares comerciales, como la IEEE 12207. No obstante, estándares como el referido anteriormente MIL-STD-498, siguieron utilizándose por empresas del sector militar.

Como extensión del desarrollo en cascada, aparece el modelo en V que pone el énfasis en la verificación y la validación. Se identifica cada fase de desarrollo (descendente) con la fase correspondiente de integración y pruebas (ascendente).

Estos modelos de desarrollo se siguen empleado en grandes proyectos de defensa, tanto en USA como en otras naciones, pero con las necesarias adaptaciones tanto al producto como a la empresa.


5 / 10

Ilustración 4 El modelo en V de desarrollo Fuente: Wikipedia[11]

Estas adaptaciones buscan mejorar la eficiencia y la productividad con el

objetivo de obtener gran calidad, tiempos de desarrollos ajustados, uso efectivo de los recursos humanos, así como bajos costes de desarrollo y mantenimiento. Para conseguir estos objetivos se plantea la posibilidad de dar un paso delante y en 2001 nace la Ingeniería de líneas de producto (“PLE en inglés”) [12]

Líneas de Producto Software (LPS)

La ingeniería de líneas de producto de sistemas y software es la forma de diseñar una familia de productos relacionados de manera eficiente, aprovechando al máximo las similitudes de los productos y respetando y gestionando sus diferencias.

El Carnegie Mellon Software Engineering Institute(SEI) define una línea de producto software (LPS) como [13]: “un conjunto de sistemas software que comparte un conjunto común de características (features), que satisfacen las necesidades específicas de un dominio o segmento particular de mercado, y que se desarrollan a partir de un sistema común de activos base (core assets) de una manera preestablecida”.

La reutilización está en el centro del desarrollo de un sistema individual, utilizando los artefactos realizados para otro sistema similar.

En la fabricación tradicional se han utilizado técnicas de ingeniería análogas para crear productos similares, empleando una única fabrica que configura y ensambla piezas diseñadas para ser reutilizadas por diferentes productos. Por ejemplo, los fabricantes de automóviles pueden crear miles de

Verificationand

ValidationProject

Definition

Concept ofOperations

Requirementsand

Architecture

DetailedDesign

Integration,Test, and

Verification

SystemVerification

and Validation

Operationand

Maintenance

ProjectTest and

Integration

ImplementationImplementation

Time


6 / 10

variaciones de un modelo de automóvil, con un conjunto único de piezas, que previamente han sido cuidadosamente diseñadas y configuradas.

La Ilustración 5 e Ilustración 6, [14] muestra la cadena de suministro, a la izquierda se configuran los activos los cuales incluyen los puntos de variación expresados en términos de características disponibles para cada uno de los productos. En la parte superior del configurador de productos, se encuentra la especificación de producto que le dice como configurar los activos que vienen de la izquierda. Los productos resultantes ya configurados salen por la derecha. La siguiente figura muestra el taller en el cual N productos son desarrollados y mantenidos. Cada producto comprende, requisitos, diseño, código fuente, casos de prueba etc. Cada ingeniero trabaja inicialmente en un único producto. Cuando se lanza un nuevo producto, el proyecto copia los activos similares y procede a adaptarlos a las necesidades del nuevo producto.

Un ejemplo práctico de la aplicación de la ingeniería de líneas de

producto es el Sistema de Combate AEGIS [15]

Ilustración 5 PLE configurador.

Ilustración 6 PLE como fábrica

Fuente: http://www.productlineengineering.com/


7 / 10

Ilustración 7 Despliegue en plataformas Navales AEGIS Fuente: [15]

El Sistema de Combate AEGIS, que lleva el nombre del mítico escudo de

Zeus, es un sistema totalmente integrado, que controla los distintos elementos, tanto armas como sensores a bordo del buque. El contratista principal es Lockheed Martin’s Mission Systems and Training Division (en adelante LM) [16]. Se estima que el sistema tiene sobre diez millones de líneas de código fuente (SLOC) y unos cien mil requisitos.

En el año 2000 se inicio el proceso de transformación de los nueve programas mas importantes del sistema, en una verdadera línea de producto. Se incluyó en este proceso la introducción de la arquitectura abierta (OA), siendo esto último un requisito impulsado por la US Navy (USN). Para LM cada uno de los nueve programas es un producto y el resultado de una línea de producto la denomina configuración.

En 2009 LM disponía de un sistema común de requisitos y código llamado “Common Source Library (CSL)”, que podia ser configurado para cualquier buque de la familia. Para la gestión de los requisitos se emplea un repositorio (base de datos DOORS), que contiene todos los requisitos de todas las configuraciones. Para las pruebas realizadas en la fase de verificación, se utiliza una aproximación que maximiza la eficiencia de las capacidades y requisitos comunes. Los problemas detectados durante las pruebas se tratan de una forma común, lo que evita que estos se propaguen por los diferentes productos.

En la actualidad “el modelo de características basado en línea de producto” está en proceso de estandarización por la International Organization


8 / 10

for Standardization (ISO 26580), con el nombre: “Methods and Tools for the Feature-Based Approach to Systems and Software Product Line Engineering” [17].

El sistema de construcción LPS es fundamental para aquellas organizaciones que tengan productos de gran tamaño, por ejemplo, los sistemas de defensa, donde no se parta desde cero, la reutilización sea importante y se pueda crear el concepto de familia.

La aplicación del modelo LPS en España.

Uno de los programas donde se aplican los conceptos de las LPS, es el programa SCOMBA (Sistema de COMbate de los Buques de la Armada) [18], desarrollado en España, nace en 2002 con el objetivo de unificar en una única familia todos los sistemas de combate de la Armada Española. El contratista principal es Navantia y su ejecución la realiza su división de Sistemas [19].

La decisión fue la de desarrollar un único sistema para las próximas plataformas en construcción en ese momento: el Buque de Aprovisionamiento al Combate (BAC) Cantabria, el Landing Helicopter Dock (LHD) Juan Carlos I y los Buques de Acción Marítima (BAM). Tres tipos de buques con misiones y requisitos distintos pero que pueden compartir el núcleo del sistema de decisión.

La comunalidad, la reutilización y la configuración son conceptos presentes desde el principio aplicándose estos tanto al Hardware como al Software. Desde el punto de vista Software se dispone de una base de datos común de requisitos y un entorno común de pruebas; las fases de definición y de pruebas se realizan para los elementos comunes. Las herramientas de configuración permiten separar las funcionalidades especificas de cada tipo de plataforma. La reducción de los tiempos de ejecución el ahorro de costes y la calidad del producto son claramente superiores a la realización de tres sistemas en paralelo.

Una dificultad añadida al desarrollo inicial fue la necesidad de disponer cuanto antes de Software operativo. Esto se solventó realizando el desarrollo en incrementos, disponiéndose de la versión completa para todas las plataformas al final del desarrollo.

Actualmente el Software SCOMBA está operativo en ocho plataformas y se está preparando para ser el sistema de combate de la futura fragata F110.


9 / 10

Conclusiones y futuro

La Ingeniería del Software ha buscado desde el inicio tener una base sólida para convertirse en una ingeniería más, desprendiéndose de ese halo de misterio y de arte que envuelve a todas las disciplinas emergentes; su evolución a lo largo de sus más de sesenta años de existencia ha sido imparable. La importancia del Software en nuestras vidas impone que la inserción de nuevos conceptos y métodos de desarrollo estén claramente consolidados en las empresas [20], para ello han de utilizar sus mejores prácticas a fin de obtener productos que satisfagan las expectativas de los clientes, en los tiempos en los que son requeridos, con una calidad adecuada y costes acotados. La reutilización de productos y subproductos procedentes del propio desarrollo es fundamental para lograr este fin, lo cual se consigue empleando un enfoque sistémico tal que el presentado por la ingeniería de líneas de producto. Compañías como, General Motors, General Dynamics, Lockheed Martin están usando este enfoque, si bien es verdad que en el sector de la Defensa es donde está teniendo más aceptación. El nuevo estándar ISO, en el que participa activamente el International Council on Systems Engineering (INCOSE) [21], servirá para difundir más ampliamente esta aproximación a la producción de Software.

Aunque el objetivo de LPS se halla claramente centrado en la reutilización y la comunalidad, otros métodos como las metodologías Ágiles, junto con LPS pueden mejorar el proceso completo, pero esto será objeto de otro artículo.

Referencias

[1] F. H. de las Telecomunicaciones, “HAMILTON, Margaret.” 2019,

[Online]. Available: https://forohistorico.coit.es/index.php/personajes/personajes-internacionales/item/hamilton-margaret.

[2] J. R. Hancock, “Margaret Hamilton, la pionera de la programación que llevó el Apolo a la Luna | Verne EL PAÍS.” 2014, [Online]. Available: https://verne.elpais.com/verne/2014/12/11/articulo/1418314336_993353.html.

[3] B. Randell, “NATO Software Engineering Conferences.” 2001, [Online]. Available: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html.

[4] G. Booch, “The History of Software Engineering,” IEEE Software, vol. 35, no. 5, pp. 108–114, 2018, doi: 10.1109/MS.2018.3571234.

[5] E. Yourdon, Modern Structured Analysis. New York: Prentice Hall, 1988. [6] T. DeMarco, “Structure Analysis and System Specification,” in Pioneers

and Their Contributions to Software Engineering, 1979.


10 / 10

[7] I. C. Society, Guide to the Software Engineering Body of Knowledge Version 3.0 (SWEBOK Guide V3.0). .

[8] “SEBoK.” https://www.sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK) (accessed Jan. 18, 2021).

[9] W. W. Royce, “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS,” 1970.

[10] U. S. D. of defense, “DOD-STD-2167A,” 1988, [Online]. Available: https://military.wikia.org/wiki/DOD-STD-2167A.

[11] wikipedia, “V-Model (software development) - Wikipedia,” 2020. https://en.wikipedia.org/wiki/V-Model_(software_development)#/media/File:Systems_Engineering_Process_II.svg.

[12] S. P. Lines, “Software Product Lines.” [Online]. Available: https://www.softwareproductlines.com/.

[13] L. M. Northrop et al., “A FRAMEWORK FOR SOFTWARE PRODUCT LINE PRACTICE, VERSION 5.0,” 2012.

[14] P. L. Engineering, “Product Line Engineering Overview.” 2018, [Online]. Available: http://www.productlineengineering.com/overview/what-is-ple.html.

[15] S. P. Gregg, R. Scharadin, E. LeGore, and P. Clements, “Lessons from AEGIS: Organizational and Governance Aspects of a Major Product Line in a Multi-Program Environment,” in Proceedings of the 18th International Software Product Line Conference - Volume 1, 2014, vol. 1, pp. 264–273, doi: 10.1145/2648511.2648541.

[16] “Aegis Combat System | Lockheed Martin.” https://www.lockheedmartin.com/en-us/products/aegis-combat-system.html (accessed Jan. 15, 2021).

[17] I. O. for Standardization, “ISO/IEC DIS 26580(en), Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering.” 2020, [Online]. Available: https://www.iso.org/obp/ui/#iso:std:iso-iec:26580:dis:ed-1:v1:en.

[18] Antonio Sanchez Godinez, “El programa Scomba,” Revista general de Marina Vol. 255, MES 7 (Julio), pp. 97–106, 2008.

[19] Navantia, “https://www.navantia.es/es/productos-y-servicios/sistemas/scomba/.” .

[20] CMMI, “CMMI Institute - Home.” https://cmmiinstitute.com/. [21] INCOSE, “INCOSE Product Line Engineering International Working

Group.” 2013, [Online]. Available: https://www.incose.org/incose-member-resources/working-groups/analytic/product-lines.

Del modelo tradicional a los modelos de reutilización del ...

Documents

Transcript of Del modelo tradicional a los modelos de reutilización del ...