En sus inicios el proceso desarrollo estaba sujeto a los lenguajes de programación C, Fortran, Cobol, entre otros; lo que conllevaba a que la programación se basará en las buenas prácticas. Con el pasar del tiempo más lenguajes aparecieron como C++, Java, Python, .NET y otros que condujeron al desarrollador a no pensar únicamente en las buenas prácticas, si no en la evolución de la aplicación y como esta se puede mantener en el tiempo.

Es la fase que sigue después de hacer el diseño del sistema, en donde ya previamente se definieron los requerimientos funcionales y se diseñó la arquitectura. El sistema se aborda por medio de la construcción de subsistemas, en algunos casos se inicia desde cero y para otros se puede hacer reutilización.

El desarrollo se puede llevar a cabo en paralelo si previamente se estructuró el sistema para que así sea. Durante todo el proceso existen revisiones de trabajo que tienen como objetivo detectar problemas, solucionarlos, identificar cambios y tomar la decisión de realizarlos de tal forma que no afecte los costos y tiempos estipulados.

Propósito general

Describir los enfoques del desarrollo de software como son la evolución, reutilización y basado en componentes.

Propósitos específicos

• Reconocer las actividades del desarrollo de software.
• Comprender que los sistemas deben evolucionar para conservar su utilidad e integración.
• Identificar las ventajas y desventajas de la reutilización de software y el uso de componentes de software comercial en el desarrollo de aplicaciones.
• Conocer las actividades del proceso CBSE.

Las operaciones en las empresas de desarrollo deben estar acorde con las peticiones del mercado; las cuales exigen nuevos productos, aumento en la demanda de competidores y entrega de productos más rápida. Los procesos de desarrollo tradicionales, como cascada, espiral, no alcanzan a cumplir con los tiempos establecidos; por esta razón, se utilizan las metodologías agiles de desarrollo, en donde se encuentran: XP, SCRUM y RUP (Sommerville, 2010).

Las metodologías ágiles se caracterizan por ser iterativas, combinan la especificación con el diseño el desarrollo y las pruebas. (Sommerville, 2010)

Bourque (2014) propone que el desarrollo es una creación detallada de software que combina las actividades de codificación, verificación, pruebas unitarias, de integración y depuración de errores. Se vincula con la KA (Knowledge Area), lo que implica un diseño y pruebas de software que son relevantes para el desarrollador. Convirtiéndose el diseño en la entrada para las pruebas y la salida de las pruebas en la entrada para el refinamiento del diseño.

En el siguiente gráfico se ve cómo la programación extrema, que hace parte de las metodologías ágiles, facilitan la construcción del software por medio de un ciclo iterativo.

Constituye las bases necesarias para que el desarrollador aborde los aspectos que se aplican en el desarrollo y posteriormente continúe con el proceso de administración. Los fundamentos de la construcción se componen de cinco elementos que en conjunto garantizan la construcción de un sistema completo, cambios, uso de la reutilización y se rige por estándares previamente definidos. Dentro de estos se destacan (Bourque, 2014):

• Minimizar la complejidad (entender el tamaño de las funcionalidades)
• Anticiparse al cambio (dimensionar los ajustes que se llegasen a presentar)
• Construcción para la verificación (probar lo hecho)
• Reutilización (usar lo que ya está)
• Estándares en la construcción (seguir reglas y procesos)

En el proceso de desarrollo existen tres tipos de modelos: los lineales, los de entrega por etapas y los iterativos.

Existen otros modelos como: desarrollo rápido de aplicaciones, basados en reutilización, versiones mejoradas de otros, programación extrema y espiral. Quienes basan sus actividades en los requerimientos, diseños y entregas prontas.

Finalmente, para llevar a cabo un buen desarrollo este debe incluir: planificación, codificación, depuración y corrección de errores, diseño, escenarios de pruebas e implementación. La administración de la construcción incluye una planificación de la construcción y medición de la construcción.

Dentro de las consideraciones practicas se encuentran las limitaciones y restricciones que enfrenta el desarrollador, donde se puede destacar los cambios en requerimientos en cualquier fase del proyecto por parte del usuario o provocados por el mismo mercado. Estas se aplican para ocho enfoques que son: diseño de construcción, lenguaje de construcción, codificación, pruebas, construcción para reutilización, construcción usando reutilización, calidad e integración.

La principal función de las tecnologías para la construcción es suministrar un grupo de técnicas y así ejecutar el proceso de desarrollo; dentro de ellas se destacan: diseño y uso de API, ejecución orientada a objetos, tecnologías genéricas, aserciones, manejo de excepciones y tolerancia a fallas, modelos ejecutables, técnicas basadas en estado y basadas en tablas, configuración de tiempo de ejecución, procesamiento de entradas, middleware, software distribuido, análisis y afinación del rendimiento, estándares de plataforma y primeras pruebas (Bourque, 2014). Se presentan en la siguiente imagen.

Involucran los entornos de desarrollo, la utilización o construcción de GUI, herramientas para las pruebas y herramientas para mejorar el rendimiento (Bourque, 2014), tal como se presenta en el medio principal de esta pantalla. Entre ellas se encuentran:

• Entornos de desarrollo
• Constructores de GUI
• Herramientas de prueba unitaria
• Herramientas de perfilado y análisis de rendimiento

En la siguiente interactividad se visualiza las etapas de la construcción de software y las tareas que se llevan dentro de cada una de ellas.

Actividad de aprendizaje

A partir de lo estudiado, construye la definición de integración y evalúa lo aprendido.

La evolución del software surge de la necesidad que tienen las organizaciones en que la inversión que han realizado no quede estancada; es decir, que conforme pasa el tiempo, el software se pueda actualizar y se mantenga funcional; puesto que hacen parte de los activos más críticos de la compañía. Estudios realizados en los últimos años muestran como las organizaciones invierten en la evolución del software actual y no la compra de nuevos productos. (Sommerville, 2010)

Esto conduce a los desarrolladores que el sistema no se detenga en el momento en que se entrega, sino que este pueda ser proyectado durante más años. La evolución se inicia con modificaciones que contribuyan a mantenerlo útil, corrección de errores, nuevos requerimientos y adaptaciones a nuevas plataformas. El entorno es un factor que por lo general crea la necesidad de evolución del software; para esto es necesario tener en cuenta si se cuenta con el presupuesto para cubrir los nuevos costos. La adaptación del software no genera inconvenientes con las relaciones o integraciones que ya tiene con otros sistemas, la infraestructura es apta y el movimiento del mercado garantiza que si es una buena inversión realizar la modificación.

En el caso en que una compañía desarrolle una aplicación, es la responsable de la evolución en el tiempo porque esta se puede adaptar por otra empresa. Si el software es personalizado, la compañía que lo adquirió es la responsable de manifestar su necesidad de evolución, la cual no se podrá realizar siguiendo un modelo espiral a causa de los vacíos en el proceso de construcción; así que no se habla de evolución sino de mantenimiento, ya que surgió tiempo después de su construcción y uso.

Un proceso es un conjunto de actividades conectadas entre sí que se realizan para conseguir un fin. Cada actividad tiene designada un responsable y los recursos que necesitará. La definición del proceso va a estar sujeto a los componentes que se modifican y cómo será su implementación. El proceso se compone de las etapas que se exponen en el gráfico principal de esta pantalla.

Otros tipos de problemas adicionales que se pueden presentar respecto al equipo que desarrolló y el equipo que ahora está a cargo de la evolución son:

• El equipo que hizo el desarrollo utilizó una metodología ágil y el nuevo equipo de evolución no conoce de estas metodologías. Se podría solventar si se cuenta con la documentación orientadora del proceso realizado.
• El equipo de desarrollo utilizó un plan normal y el de evolución prefiere un método ágil; esto conlleva a comenzar con la generación de pruebas automatizadas y refactorización de código o hasta reingeniería.

XP es un modelo de desarrollo que se usa frecuentemente para el mantenimiento.

Hacia los años 80 se dio inicio a estudios para identificar los cambios que ocurren en los sistemas. Este estudio produjo lo que hoy se conoce como las Leyes de Lehman, las cuales se explicaron en la anterior interactividad.

Es el proceso que se produce posteriormente a las entregas del sistema por completo. Adicional se debe tener en cuenta que al hacer software, y poderlo mantener por un buen tiempo, se incurrirá en otros costos que no se tenían contemplados.

Por otro lado, las métricas facilitan medir el desempeño y la eficacia del mantenimiento que se debe realizar:

• Número de peticiones: conocer la cantidad de peticiones de corrección de errores que se generaron durante el mantenimiento.
• Tiempo: cuántos componentes solicitaron ajustes y cuánto fue el tiempo entre una solicitud y otra.
• Tiempo para realizar un cambio: control de cuánto es el tiempo en el cual se cumple un cambio; si el tiempo va en aumento quiere decir que necesita mayor atención el mantenimiento.
• Número de peticiones: contabilizar cuánto de las peticiones de cambio aún se encuentran pendientes por realizar. En la siguiente imagen se observan el ciclo y sus tareas.

Aplica para los sistemas que han sido heredados y necesitan de mantenimiento. La reingeniería es un proceso que consiste en estructurar, entender, documentar, refactorizar su arquitectura, llevar del lenguaje de programación en el que fue elaborado el programa a un lenguaje de programación más moderno y modificar el sistema. Garantizando que su funcionalidad seguirá siendo la misma y que la arquitectura no tendrá grandes cambios.

A continuación se presentan las ventajas y desventajas de la reingeniería.

Como todo sistema necesitan un seguimiento para sus procesos de planeación, integración, desarrollo y posterior evolución. Debe tenerse en cuenta el presupuesto que se utilizará para el mantenimiento y actualización en el tiempo. Adicional hay que contar con opciones estratégicas.

Para la valoración de un sistema en la organización se tiene en cuenta los siguientes interrogantes: ¿el sistema se usa constantemente? ¿qué tan esencial es el sistema para la organización? ¿el sistema es flexible?, ¿se ajusta a los cambios de la organización? ¿todo el sistema es confiable? ¿cuándo se presentan problemas en el sistema, afecta al cliente o a los trabajadores? ¿son las salidas que genera el sistema importantes? Contestando cada una de estas preguntas, realmente la organización puede determinar qué valor tiene el sistema.

Actividad de aprendizaje

Recuerda las tareas que involucra la evolución: mantenimiento, predecir el mantenimiento y la reingeniería de software. De ser necesario, remítase a la sección evolución del software del material de estudio y conteste en siguiente test de evolución.

Hacia el año de 1968 se introdujo el tema de la reutilización, no fue sino hasta el año 2000 donde comenzó a tener más auge; surge como la respuesta a la gran demanda que tiene actualmente el desarrollo del software con respecto a la disminución de costos para producir, mantener un software por un determinado tiempo, entregar más rápido un sistema y tener una excelente calidad del producto que se entrega.

Por otro lado, las compañías de desarrollo cambiaron su mentalidad del código fuente cerrado a un código fuente abierto, esto quiere decir que las librerías, componentes, ejecutables o aplicaciones completas se encuentran a disposición de quien las considere útiles para ajustar y adaptar a sus necesidades.

A continuación se presentan las ventajas, desventajas y el enfoque de la reutilización.

La reutilización es comúnmente utilizada con la programación orientada a objetos y dentro de ella se hace uso de los frameworks, que se definen como un conjunto de software previamente integrado, que contribuye en el proceso de reutilización de una determinada aplicación (Sommerville, 2010).

La implementación de un frameworks está dada por el lenguaje de programación que se esté utilizando. Su uso va desde la creación de toda una aplicación hasta una sola parte de la misma. Existen cuatro tipos, estos son (Schmidt, 2004): de infraestructura, integración, aplicación y aplicación web.

La implementación de un frameworks se hace de forma sencilla mediante la agregación de clases que heredan las operaciones de otras clases ya establecidas. Por otro lado, se debe utilizar los callbacks (volver a llamar) que no son otros sino respuestas a los eventos llamados en el frameworks.

Es un conjunto de aplicaciones que tienen en común la misma arquitectura y comparten una serie de componentes y cumplen con diferentes requerimientos. Se basa en un diseño centrado para que de esta forma pueda adaptarse, configurarse a cualquier tipo de usuario, implementar más componentes o realizar modificaciones en los existentes (Sommerville, 2010).

Con las líneas de productos de software se construye una base genérica que se presta para ser utilizada por otros sistemas; sin que los cambios afecten a la base ya plenamente definida. En la tabla se reconocen las diferencias entre frameworks y líneas de productos.

Para extender una línea de productos de software para la creación de una nueva aplicación es necesario llevar a cabo cinco pasos. El proceso de desarrollo, por su parte, se compone de dos etapas, donde se configura el tiempo respecto al momento de diseño y a la implementación. En la siguiente interactividad se desarrollaran los pasos y etapas de ambos aspectos.

Un ejemplo de definición de la arquitectura de una línea de productos puede ser el manejo de salidas de vehículos para servicios de emergencia. El operario recibe la llamada de un incidente, ubica un vehículo y es enviado a donde es solicitado (Sommerville, 2010). A continuación se presentan las cuatro capas que componen la definición de la arquitectura de un sistema de despacho de vehículos para cubrir emergencias.

Los COTS (Commercial off the shelf) son sistemas de software que pueden ser adaptados a las necesidades de los clientes sin que sea necesario modificar el código fuente. Este tipo de sistemas se construye de forma que los ajustes se realicen de forma interna.

Para la reutilización de COTS el cliente debe revisar los dos tipos de reutilización que existen: los sistemas de solución son genéricos y pertenecen a un proveedor que permita configurarse de acuerdo con las necesidades del cliente. Los integrados conllevan de dos o más sistemas en adelante.

Actividad de aprendizaje

De acuerdo a lo estudiado sobre los enfoques de reutilización, realiza la siguiente actividad de relación de columnas.

Surge como respuesta efectiva para hacer reutilización de software, cuando los productos COTS no suplen todas las necesidades de la organización y se debe desarrollar un nuevo sistema. Se dio a conocer en 1990 como CBSE (Component Based Software Engineering). El cliente exige actualmente que el software sea confiable, entregas e implementaciones prontas que no dan espera. Para su uso se debe establecer un proceso de definición, implementación e integración de componentes independientes (Sommerville, 2010).

La CBSE brinda apoyo para la ingeniería de software que hace reutilización como a la ingeniería distribuida; trata al componente como un elemento de un sistema que puede ser accedido mediante procedimientos remotos y se ejecutan en máquinas independientes. En la industria del software se han construido protocolos y estándares que contribuyen con el proceso, dentro de estos se encuentran: EJB (Enterprise Java Beans), COM, .NET y el ya mencionado en sistemas distribuidos CORBA.

El componente es un elemento que hace parte de un sistema. Entre sus características está la independencia y se consideran como unidades fundamentales en el proceso de composición de software. Los componentes fueron diseñados de forma que ofrezcan desde uno a varios servicios. Un ejemplo de esto es: el componente de búsqueda en una biblioteca, pues le permite a los usuarios realizar búsquedas en diferentes catálogos (Bruegge, 2004).

Los modelos de componentes se basa en la definición de los estándares para una correcta implementación, generación de documentos y despliegue de los componentes. Esta información es útil para que el desarrollador tenga certeza de cómo operarlos.

Procesos CBSE

Son el soporte a la CBSE, respecto a la reutilización y todas las actividades que ameritan. Existen dos tipos: para reutilización y con reutilización.

La implementación de los componentes se divide en categorías estas son: a nivel de plataforma, son los servicios que los componentes ofrecen para comunicarse e interoperar en sistemas distribuidos. A nivel de apoyo, servicios comunes que necesitan de otros componentes. Cualquiera de las dos categorías garantiza la disminución en los costos de desarrollo de componentes y evita la incompatibilidad que en ocasiones se presenta entre componentes (Amescua, 2003).

Para el diseño de componentes se puede seguir la guía de los principios básicos de diseño, los cuales buscan crear aplicaciones que sean fáciles de cambiar y no tenga efectos colaterales como consecuencia de los cambios. Estos se explican en el gráfico principal de esta pantalla.

Los pasos descritos a continuación hacen parte de las tareas que se realizan para un diseño de componentes en un sistema orientado a objetos. Estudia cada uno de ellos.

Para realizar el proceso de composición de componentes hay que identificar primero cuáles serán los conflictos que se presentarán. Por un lado, entre los requerimientos funcionales y los no funcionales, la necesidad de entregarlo de forma rápida y que evolucione conforme cambian los requerimientos.

Existen tres formas diferentes para hacer la composición de componentes: secuencial, jerárquica y aditiva.

Los inconvenientes que se presentan con la composición de componentes, de acuerdo con Sommerville (2010), son: Parámetros incompatibles: operaciones de interfaces con el mismo nombre pero la cantidad o los tipos de parámetros son diferentes. Operaciones incompatibles: en las interfaces que requiere o proporciona sus nombres son diferentes. Operaciones que no terminan: la interfaz proporciona a un componente pero requiere de otro para terminar o viceversa. La solución para estos inconvenientes es construir un adaptador que haga la comunicación entre las interfaces de los componentes requeridos.

Actividad de aprendizaje

Según lo estudiado en este punto, agrupa los datos de Ingeniería de Software Basada en Componentes y evalúa lo aprendido.

En la unidad se abordó el tema de desarrollo que incluía cinco grupos de elementos que son útiles para el desarrollador como es el caso de la anticipación al cambio, realizar una construcción que conlleve a una verificación, seguir estándares y reutilizar. Una vez se definieron estos aspectos se contempla el seguimiento a un plan de construcción donde es importante medir tiempos, costos, análisis de rendimiento y las herramientas que se utilizan para asegurar un mejor desempeño del producto. Veamos un gráfico resumen de esta unidad.

Las actuales tecnologías proporcionan herramientas necesarias para la construcción como lo son: las API unidades de software, la programación orientada a objetos que genera pensar en objetos, atributos y relaciones entre los mismos. Controlar y dar un buen manejo a los errores que se le llegase a presentar al usuario. Construcción de sistemas distribuidos o en otras ocasiones sistemas heterogéneos. Contar con buenas plataformas de desarrollo, de diseño y de pruebas.

El reto que tienen las empresas de software en este momento es poder hacer evolución de los aplicativos, sin que esto afecte su funcionamiento actual. Se requiere que previamente sea elaborado un plan de evolución donde contemple fases, tareas y recursos de hardware y software con los cuales se alcance la evolución (Schach, 2006).

Por cuestiones de tiempos cortos y disminución de costos en el desarrollo, la reutilización de software es una excelente solución, pero es necesario que quién reutilice cuente previamente con los componentes ya sea porque están dentro del repositorio de la línea de productos de la organización o porque están disponibles en el mercado, como es el caso de los COTS.

Finalmente, la ingeniería basada en componentes se fundamenta en las buenas prácticas de las organizaciones de desarrollo de software.

Caso de estudio

Lee el siguiente caso de estudio y resuelve un par de preguntas. Ten en cuenta todo lo estudiado en la unidad.

Material de apoyo