Ingeniería del Software Libre (ISL)

Ingeniería del Software libre

Para entender la Ingeniería de Software Libre, primeramente hay que tener claro el concepto de ingeniería del software, el cual se define como una disciplina que tiene el propósito de diseñar, crear y mantener el software por medio de la aplicación de tecnologías y prácticas de las ciencias de la computación, administración de proyectos, ingeniería, dominio de aplicaciones, diseño de interfaces, administración de componentes digitales y otros campos.

La ingeniería del software se relaciona con la aplicación de los principios de ingeniería de la concepción, desarrollo y verificación y depuración de sistemas de software. Esta disciplina está de acuerdo con identificar, definir, realizar y verificar las características requeridas del software resultante. Esas características del software pueden incluir, la funcionalidad, la confiabilidad, la mantenibilidad, la disponibilidad, la testeabilidad, la facilidad de uso, la portabilidad y demás atributos. La Ingeniería del Software direcciona dichas características por medio de diseños preparados y especificaciones técnicas que, si se implementan de forma correcta, darán como resultado un software que puede ser verificado para cumplir con dichos requerimientos.

A pesar del hecho de que el desarrollo del software libre cuenta con varias décadas de crecimiento, es sólo desde hace unos pocos años que se ha empezado a prestar atención a sus modelos y procesos de desarrollo desde el punto de vista de la ingeniería del software. De la misma forma que no existe un único modelo de desarrollo de software propietario, tampoco existe uno en el mundo del software libre, pero aun así se pueden encontrar características interesantes que comparten gran parte de los proyectos estudiados, y libres.

Con la Ingeniería de Software Libre se pretende promover el uso de sistemas operativos, lenguajes de programación, bases de datos y demás herramientas de software de carácter libre para la creación de aplicaciones.

La ingeniería del software libre cuenta como objetivo a corto plazo poder realizar un análisis completo al desarrollo de software libre que permita indagar profundamente en los procesos que están involucrados, así como en las consecuencias que ciertas acciones tienen sobre el conjunto del desarrollo.

Cabe añadir, sin embargo, que la ingeniería del software libre no sólo pretende ser beneficiosa para la ingeniería del software; también lo pretende ser, en gran medida, para el software libre. Si a día de hoy los cálculos de plazos y de costes en los proyectos de software estudiados tradicionalmente (en su gran mayoría de software propietario) son difícilmente cuantificables, dentro del mundo del software libre son prácticamente utópicos.

La comparación entre diferentes proyectos de software libre, así como el análisis de aquéllos que tienen éxito también debe servir para que la experiencia en la creación de software libre quede plasmada en conocimiento para proyectos futuros. En este sentido, paradójicamente, la ingeniería del software libre puede ser la puerta de entrada de métodos auspiciados por la ingeniería del software tradicional que se muestren exitosos o eficaces en proyectos de software libre.

Metodologías para Desarrollo de Software

Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

A continuación se revisan brevemente cada una de estas categorías de metodologías:

Metodologías Estructuradas
 

Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.

Metodologías Orientadas a Objetos

Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad.

Algunas metodologías orientadas a objetos que utilizan la notación UML son:

• Rational Unified Process (RUP)
• OPEN
• MÉTRICA (que también soporta la notación estructurada)

Metodologías Tradicionales

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

Metodologías Ágiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento).
 

Entre las metodologías ágiles identificadas son:

• Extreme Programming
• Scrum
• Familia de Metodologías Crystal
• Feature Driven Development
• Proceso Unificado Rational, una configuración ágil
• Dynamic Systems Development Method
• Adaptive Software Development
• Open Source Software Development

 

Las metodologías ágiles y el Software Libre han crecido a la par ya que se enfocan en una organización menos formal y jerárquica, dándole mayor prioridad a las personas, y enfocándose en el desarrollo de las mínimas características necesarias para obtener un sistema de calidad y satisfacer al cliente. 

Algunas relaciones que existe entre las metodologías ágiles con el SL:

Principios de las metodologías ágiles	Relación con SL
Personas e interacciones en vez de procesos	Desarrollo en comunidades, por lo que se orienta al desarrollo en equipo
Software funcional en vez de documentación excesiva	El código debe funcionar bien ése es su principal fuente de documentación, además de los foros y extractos de código y capturas de pantalla.
Colaboración con el cliente en vez de enfatizar un contrato	En el SL el desarrollador y el usuario coinciden con frecuencia.
Responder al cambio por encima de seguir la planificación	De acuerdo con el gran principio de colaboración los desarrolladores se enfocan dar prontas respuestas en mejoras, desarrollos y cambios

 

Modelos De Proceso De Software

• Codificar y corregir
• Modelo en cascada
• Desarrollo evolutivo
• Desarrollo formal de sistemas
• Desarrollo basado en reutilización
• Desarrollo incremental
• Desarrollo en espiral

Codificar y corregir (Code-and-Fix)

Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:

1. Escribir código.
2. Corregir problemas en el código.

Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y Mantenimiento.

Este modelo tiene tres problemas principales:

Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos.

Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.

El código es difícil de reparar por su pobre preparación para probar y modificar.


Modelo en cascada

El modelo en cascada consta de las siguientes fases:

Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.

 

Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.

Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad. Departamento de Sistemas Informáticos y Computación.

Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.

Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.

Algunos problemas que se observan en el modelo de cascada son:

• Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.
• Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.
• Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.
• Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.
• Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.

Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.

Desarrollo evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.

Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.
• Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos.

El prototipo ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo están:

• La especificación puede desarrollarse de forma creciente.
• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.
• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:

• Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.
• Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.
• Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

Desarrollo formal de sistemas

Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.

Observaciones sobre el desarrollo formal de sistemas:

• Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.
• Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.
• Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en reutilización

Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización.

Este modelo consta de 4 fases que se describe cada fase:

• Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
• Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).
• Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.
• Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Desventajas de este modelo:

• Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.
• Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.

Procesos iterativos

A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:

1. Desarrollo Incremental.
2. Desarrollo en Espiral.

Desarrollo incremental

Es una combinación del Modelo de Cascada y Modelo Evolutivo.

Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema.

Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Entre las ventajas del modelo incremental se encuentran:

• Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.
• Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.
• Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.
• Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

• Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
• Cada incremento debe aumentar la funcionalidad.
• Es difícil establecer las correspondencias de los requisitos contra los incrementos.
• Es difícil detectar las unidades o servicios genéricos para todo el sistema.

Desarrollo en espiral

Es actualmente uno de los más conocidos y fue propuesto por Boehm El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.

Cada ciclo de desarrollo se divide en cuatro fases:

• Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
• Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.
• Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.
• Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.

Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.

El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema.

Ingeniería del Software Libre y UML

El lenguaje unificado de diagrama o notación (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que simplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros.

Esta notación es un estándar para modelar sistemas, desde diferentes vistas o niveles de abstracción, que pueden ir desde la definición del problema (casos de uso), la vista lógica (clases, objetos), la vista de procesos (comportamiento), implementación y hasta distribución. Es tan amplia que incluso ayuda a entender procesos de negocio complejos, lo cual lo convierte en una buena herramienta de comunicación entre las diferentes capas, participantes y clientes de un proyecto

UML se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema. En UML existen cinco vistas que permiten, visualizar, especificar, construir y documentar la arquitectura del software. UML permite representar cada vista mediante un conjunto de diagramas. Tal y como se describe a continuación:

• Vista de caso de uso: muestra la funcionalidad del sistema desde el punto de vista de un actor externo que interactúa con él. Esta vista es útil a clientes, diseñadores y desarrolladores.
• Vista de diseño: muestra la funcionalidad del diseño dentro del sistema en términos de la estructura estática y comportamiento dinámico del sistema. Esta vista es útil a diseñadores y desarrolladores.
• Vista de procesos: muestra la concurrencia del sistema, comunicación y sincronización. Útil a desarrolladores e integradores.
• Vista de implementación: muestra la organización de los componentes de código. Útil a los desarrolladores.
• Vista de implantación o despliegue: muestra la implantación del sistema en la arquitectura física. Útil a desarrolladores, integradores y verificadores.

Existen muchas opciones a la hora de elegir una herramienta basada en software libre para trabajar con UML, entre ellas están:

ArgoUML: es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java. El Magazine de Desarrollo de Software entrega premios anuales a herramientas de desarrollo de software populares en varias categorías. En 2003 ArgoUML fue una de las finalistas en la categoría “Design and Analysis Tools”. ArgoUML recibió un premio “runner-up” (revelación), derrotando a muchas herramientas comerciales.

Umbrello: es una herramienta de diagramas que ayuda en el proceso del desarrollo de software. Umbrello facilita la creación de un producto de alta calidad, especialmente durante fases de análisis y diseño del proyecto. UML también puede usarse para documentar sus diseños de software para ayudarle a usted y al resto de desarrolladores.

StarUML: es una herramienta para el modelamiento de software basado en los estándares UML (Unified Modeling Language) y MDA (Model Driven Arquitecture), que en un principio era un producto comercial y que hace cerca de un año paso de ser un proyecto comercial (anteriormente llamado plastic) a uno de licencia abierta GNU/GPL.

BoUML: Esta también es una herramienta CASE gratuita (licencia GPL). Permite trabajar con UML 2, soporta gran cantidad de diagramas, es rápida y apenas consume memoria, es sencilla de utilizar, permite generar código para Java, C++ e IDL, y puede hacer reingeniería inversa (a partir del código sacar el modelo). También es capaz de generar documentación en varios formatos (HTML, XMI, etc.)

Dia: es un programa de creación de diagramas basado en GTK+ bajo la licencia GPL. Está inspirado en el programa comercial de Windows ‘Visio’, y puede ser usado para dibujar muchos tipos diferentes de diagramas. Dispone de una serie de extensiones para ayudar en la elaboración de diagramas entidad-interrelación, UML, flujo de datos, diagramas de red, y un largo etc. Pero muchos al usarlo tal vez puedan sentir una frustración ya que no es muy sencillo de usar y se trata ‘solamente’ de una herramienta de dibujo de diagramas, evitando que podamos sacarle todo el provecho que se podría sacar del UML. Dia incluye una herramienta para generar código a partir de los diagramas realizados.

Existen muchas otras como: Frame UML y TinyUML, pero es necesario informar que la mayoría de estas herramientas se encuentran en fase de desarrollo, por lo tanto aun poseen muchas carencias y detalles técnicos que solventar. La herramienta más recomendada, por lo que ofrece y porque ha logrado superar incluso a herramientas CASE para UML comerciales, son ArgoUML y StarUML, estas son las que se han ubicado entre las preferidas y las más completas por sus múltiples opciones de diseño y sus incorporaciones que no le envidian nada a las herramientas de software propietario.

Mapa Mental Ingeniería del Software Libre