Aspectos Legales y Licenciamiento Software Libre

Licenciamiento del Software

Los programas o software en Internet son distribuidos bajo una licencia, estas licencias fueron creadas con el fin de evitar estafas, o falsificaciones. Acá encontrara información detallada sobre qué son y los tipos de licencias.

En sentido general una licencia es un contrato, el cual se utiliza para que un tercero reciba el derecho de uso sobre un bien material o inmaterial. A cambio del uso, el tercero paga un monto de dinero, determinado por el propietario de la licencia.

Para poder obtener la patente de una marca y cobrar por la licencia. La marca debe estar previamente registrada en una cámara de comercio y estar contribuyendo con los respectivos impuestos. Una marca o compañía debe tener un represéntate el cual actúa como persona jurídica.

Se puede decir que la importancia de las licencias son:

1. El autor tiene control legal casi absoluto de su obra publicada.
2. En particular, si no da su permiso no se puede copiar, redistribuir, modificar, ampliar, etc.
3. El autor puede ceder su control a otros (total o parcialmente).
4. Usando este mecanismo, el autor puede garantizar permisos “automáticos” a otros.
5. Para ello, utiliza la licencia de redistribución de la obra.
6. Importante: la licencia “funciona” en el momento de la redistribución.
7. No hace falta licencia si la obra está en el “dominio público” (su autor la colocó ahí o expiró el periodo de derechos de autor). 

Las licencias empleadas dentro del Software son las siguientes:

GPL: La Licencia Pública General GNU (GNU General Public License GPL) es la licencia que acompaña los paquetes distribuidos por el Proyecto GNU, más una gran variedad de software que incluye el núcleo del sistema operativo Linux.

Copyleft: La mayoría de las licencias usadas en la publicación de software libre permite que los programas sean modificados y redistribuidos. Estas prácticas están generalmente prohibidas por la legislación internacional de copyright, que intenta impedir que alteraciones y copias sean efectuadas sin la autorización del o los autores. Las licencias que acompañan al software libre hacen uso de la legislación de copyright para impedir la utilización no autorizada, pero estas licencias definen clara y explícitamente las condiciones bajo las cuales pueden realizarse copias, modificaciones y redistribuciones, con el fin de garantizar las libertades de modificar y redistribuir el software registrado. A esta versión de copyright, se le da el nombre de copyleft.

Debian: La licencia Debian es parte del contrato realizado entre Debian y la comunidad de usuarios de software libre, y se denomina Debian Free Software Guidelines (DFSG). En esencia, esta licencia contiene criterios para la distribución que incluyen, además de la exigencia de publicación del código fuente: (a) la redistribución libre ; (b) el código fuente debe ser incluido y debe poder ser redistribuido; (c) todo trabajo derivado debe poder ser redistribuido bajo la misma licencia del original; (d) puede haber restricciones en cuanto a la redistribución del código fuente, si el original fue modificado; (e) la licencia no puede discriminar a ninguna persona o grupo de personas, así como tampoco ninguna forma de utilización del software; (f) los derechos otorgados no dependen del sitio en el que el software se encuentra; y (g) la licencia no puede 'contaminar' a otro software.

 

BSD: La licencia BSD cubre las distribuciones de software de Berkeley Software Distribution, además de otros programas. Ésta es una licencia considerada 'permisiva', ya que impone pocas restricciones sobre la forma de uso, alteraciones y redistribución del software. El software puede ser vendido y no hay obligaciones de incluir el código fuente. Esta licencia garantiza el crédito a los autores del software pero no intenta garantizar que las modificaciones futuras permanezcan siendo software libre.

X.org: El Consorcio X distribuye X Window System bajo una licencia que lo hace software libre, aunque sin adherirse al copyleft. Existen distribuciones bajo la licencia de la X.org que son software libre, y otras distribuciones que no lo son. Existen algunas versiones no-libres del sistema de ventanas X11 para estaciones de trabajo y ciertos dispositivos de IBM-PC que son las únicas funciones disponibles, sin otros similares que sean distribuidos como software libre.

Software Semi-libre: El Software semi-libre es un software que no es libre pero permite que otros individuos lo usen, lo copien, lo distribuyan y hasta lo modifiquen. Ejemplos de software semi-libre son las primeras versiones de Internet Explorer de Microsoft, o algunas versiones de browsers de Netscape, y StarOffice.

Freeware: El término freeware no posee una definición ampliamente aceptada, pero es utilizada para programas que permiten la redistribución pero no la modificación, y que incluyen su código fuente. Estos programas no son software libre.

Software con Dominio Público: El Software con dominio público es software sin copyright. Algunos tipos de copia o versiones modificadas pueden no ser libres si el autor impone restricciones adicionales en la redistribución del original o de trabajos derivados.

Shareware: Shareware es el software disponible con el permiso para que sea redistribuido, pero su utilización implica el pago. Generalmente, el código fuente no se encuentra disponible, y por lo tanto es imposible realizar modificaciones.

Software Propietario: El Software propietario es aquel cuya copia, redistribución o modificación están, en alguna medida, prohibidos por su propietario. Para usar, copiar o redistribuir, se debe solicitar permiso al propietario o pagar.

Software Comercial: El Software comercial es el software desarrollado por una empresa con el objetivo de lucrar con su utilización. Nótese que "comercial" y "propietario" no son lo mismo. La mayor parte del software comercial es propietario, pero existe software libre que es comercial, y existe software no-libre que no es comercial.

Licencia Pública General

Los principios que inspiran al software libre y que se garantizan a través del Copyleft, se logran gracias a la adopción del sistema de Licencia Pública General (LPG) o en ingles Public General License (PGL). El proyecto GNU (No es Unix) y las condiciones de distribución y redistribución del software libre, se encuentran claramente definidas en cuanto a sus términos y alcances en la Licencia Pública General (LPG). La licencia respectiva es incluida en cada paquete y hace parte de cada una de las distribuciones que se hace del código fuente de los programas GNU.

Así por ejemplo existe una Licencia Pública General para Bibliotecas (Library General Public License - LGPL), la cual ha sido rediseñada luego de que la misma se presto para usos incorrectos por parte de algunos de su usuario. La GPL lo que busca en ultimas es crear unos parámetros o standard generales en el licenciamiento del software libre, haciéndolos compatibles entre si.

Actualmente la versión oficial de la GPL aprobada por la Fundación de Software Libre se encuentra en idioma ingles, y no se han aprobado traducciones oficiales de la misma a otras lenguas para evitar tergiversaciones o interpretaciones erróneas. Sin embargo, existen una serie de traducciones no oficiales a varios idiomas (Alemán, Francés, Croata, Español, Italiano, Koreano, japonés, Ruso, Eslovaco, Portugués, Finlandés, Rumano, Gallego, Tailandés, Chino e Indonesio), que servirán de parámetro para entender en alguna medida de mejor manera la GNU - GPL.

Aspectos Legales Relacionados con el Licenciamiento del SL

 

 

Propiedad Intelectual: La propiedad intelectual supone el reconocimiento de un derecho particular en favor de un autor u otros titulares de derechos, sobre las obras del intelecto humano. En los términos de la Declaración Mundial sobre la Propiedad Intelectual, es entendida similarmente como "cualquier propiedad que, de común acuerdo, se considere de naturaleza intelectual y merecedora de protección, incluidas las invenciones científicas y tecnológicas, las producciones literarias o artísticas, las marcas y los identificadores, los dibujos y modelos industriales y las indicaciones geográficas”.

La Propiedad Intelectual involucra tanto a las obras artísticas y literarias como a las invenciones que pueden tener una aplicación industrial, es decir que incluye los derechos de autor y de inventor.

 

Propiedad Industrial: La propiedad industrial se refiere al derecho sobre las patentes de invención, los modelos de utilidad, los dibujos o modelos industriales, las marcas de fábrica o de comercio, las marcas de servicio, el nombre comercial, las indicaciones de procedencia o denominaciones de origen.

Al tratarse de un tipo de propiedad intelectual, ésta guarda una estrecha relación con creaciones del ingenio humano como las invenciones y los dibujos y modelos industriales. Las invenciones se constituyen como soluciones a problemas técnicos y los dibujos y modelos industriales son las creaciones estéticas que determinan la apariencia de productos industriales. Además, la propiedad industrial incluye las marcas de fábrica o de comercio, las marcas de servicio, los nombres y designaciones comerciales, incluidas las indicaciones de procedencia y denominaciones de origen, y la protección contra la competencia desleal.

 

Derechos de Autor: Es la protección que le otorga el Estado al creador de las obras literarias o artísticas desde el momento de su creación y por un tiempo determinado.

Los derechos de autor del software no son, en esencia, diferentes a cualquier otro tipo de derechos de autor. Sin embargo, hay determinados aspectos de la legislación que son específicos del software, dado que existen diferencias prácticas entre el software y otros elementos que pueden ser protegidos por derechos de autor (libros, poemas, dibujos, esculturas, etc.). La legislación relativa a derechos de autor concede al programador (o, en el caso de que se trate de un programador asalariado, a su empresario) un alto grado de control sobre el programa que ha creado. En concreto, es ilícito que un tercero distinto al titular de los derechos ejecute, copie, transforme o distribuya el programa, salvo con previa autorización del titular de los derechos.

Patentes: Una patente es un derecho exclusivo concedido a una invención, es decir, un producto o procedimiento que aporta, en general, una nueva manera de hacer algo o una nueva solución técnica a un problema. Para que sea patentable, la invención debe satisfacer determinados requisitos.

Las patentes de software tienen un papel relevante dentro de software libre, porque plantean la única amenaza contra la cual la comunidad del software libre no puede defenderse. Los problemas de copyright y de marcas registradas siempre se pueden sortear. Si parte de tu código parece que podría infringir el copyright de otro, puedes reescribir esa parte. Si resulta que alguien tiene el nombre de tu proyecto como marca registrada, en el peor de los casos puedes simplemente cambiársela. A pesar de que cambiar nombres puede ser una inconveniencia temporal, no debería importar a largo plazo, ya que el propio código haría lo que siempre hizo.

 

Marcas: La marca es el signo protegido en virtud de su inscripción en el Registro de la Propiedad Industrial (SAPI), que pertenece a una persona natural o jurídica y se utiliza para distinguir productos y/o servicios en el mercado permitiendo su diferenciación de otras personas que fabriquen o comercialicen el mismo producto.

A través de ella el consumidor puede conocer la procedencia del artículo que adquiere para que elija el producto y/o servicio de su preferencia; y al titular que comercialice su producto o servicio sin el riesgo de que se confundan con elementos o servicios análogos, garantizándoles la reputación y aceptación del mismo.

 

Secretos Industriales: Es la información que posee una persona o empresa sin revelarla públicamente, y que le da cierta ventaja económica.

La definición de secreto industrial tiene los siguientes conceptos generales son:

 

• Es información que ofrece alguna ventaja competitiva o económica respecto a otros. 
• La persona o empresa que obtuvo o desarrolló esa información la guarda en secreto y adopta las medidas para conservarla confidencial, por ejemplo manteniendo un acceso restringido a la misma. 
• Consta en algún medio: papel, electrónico, magnético, óptico, etc. No es verbal solamente.

La persona o empresa puede transmitir el secreto a otros, u otorgar licencias de uso. Los empleados, consultores, proveedores, etc. que tengan acceso a un secreto industrial, siempre y cuando fueron prevenidos de esto, quedan obligados a no revelarlo sin permiso.

Las leyes generalmente definen penas económicas por la divulgación o uso sin autorización de un secreto industrial. No es necesario registrar un secreto industrial para que esté protegido por la ley. La duración es indefinida, hasta que la información llegue a ser desarrollada independientemente por otra persona o competidor

 

Diferencia entre los Principios del Software Libre y los del Código Abierto 

 

En realidad, se trata de dos conceptos con muchas similitudes pero, en el fondo de ambos términos, lo que realmente les diferencia es que el “software libre” se centra más en la libertad del individuo, mientras que el “código abierto” se centra más en conceptos prácticos no relacionados con el individuo, sino con el software en si. Según Richard Stallman, padre del proyecto GNU y de la FSF (Free Software Foundation), para que una aplicación pueda considerarse como software libre debe cumplir lo que él ha dado en llamar las cuatro libertades, que son:

- Libertad 0: La “libertad” para ejecutar el programa con cualquier propósito.
- Libertad 1: La “libertad” para estudiar y modificar el programa.
- Libertad 2: La “libertad” de copiar el programa y ayudar con él a tu vecino.
- Libertad 3: La “libertad” de mejorar el programa, y hacer públicas tus mejoras, de forma que se beneficie toda la comunidad.

Por otro lado, para que un programa sea considerado como “código abierto” debe cumplir el siguiente decálogo:

- Punto 1: Libre redistribución: el software debe poder ser regalado o vendido libremente.
- Punto 2: Código fuente: el código fuente debe estar incluido u obtenerse libremente.
- Punto 3: Trabajos derivados: la redistribución de modificaciones debe estar permitida.
- Punto 4: Integridad del código fuente del autor: las licencias pueden requerir que las modificaciones sean redistribuidas sólo como parches.
- Punto 5: Sin discriminación de personas o grupos: nadie puede dejarse fuera.
- Punto 6: Sin discriminación de áreas de iniciativa: los usuarios comerciales no pueden ser excluidos.
- Punto 7: Distribución de la licencia: deben aplicarse los mismos derechos a todo el que reciba el programa
- Punto 8: La licencia no debe ser específica de un producto: el programa no puede licenciarse solo como parte de una distribución mayor.
- Punto 9: La licencia no debe restringir otro software: la licencia no puede obligar a que algún otro software que sea distribuido con el software abierto deba también ser de código abierto.
- Punto 10: La licencia debe ser tecnológicamente neutral: no debe requerirse la aceptación de la licencia por medio de un acceso por clic de ratón o de otra forma específica del medio de soporte del software.

Como vemos, ambos conceptos se parecen mucho, pero mientras que en uno (software libre) prima la ética de la “libertad del individuo”, en el otro (código abierto) sólo se tienen en cuenta conceptos relativos al propio software.

Lenguaje Unificado de Modelado (UML)

UML

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.

UML, ¿Método o Lenguaje de Modelado?


UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).

figura 1

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

Vista de Componentes: Muestra la organización de los componentes de código.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.


Fases del Desarrollo de un Sistema

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

UML ofrece 9 tipos de diagramas con los cuales se pueden modelar sistemas:

• Diagrama de Casos para Uso para modelar los procesos "business"
• Diagrama de Secuencia para modelar el paso de mensajes entre objetos
• Diagrama de Colaboración para modelar interacciones entre objetos
• Diagrama de Estado para modelar el comportamiento de los objetos en el sistema
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagrama de Clases para modelar la estructura estática de las clases en el sistema
• Diagrama de Objetos para modelar la estructura estática de los objetos en el sistema
• Diagramas de Componentes para modelar componentes
• Diagrama de Implementación para modelar la distribución del sistema

Paradigma Orientado a Objeto

La orientación a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos.

En otras palabras Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento específico.

Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes , subpartes y sub-subpartes,etc.

La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que estén basados esta metodología. Por eso, revisaremos los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.

Es importante conocer la base del diseño y programación de buenas clases, tanto por si solas como a través del uso de herencia. Asi como el concepto de subtipos, como concepto teórico que está detrás de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Más tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseño, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, proveer mecanismos para verificar si una clase y las relaciones entre ellas están bien diseñadas, y en particular si la herencia está bien usada.

Esto es fundamental para que los diseños a objetos no sean más complicados de entender que los de procedimientos y para que el software que se diseñe sea reusable y fácil de extender. Finalmente presenta los aspectos más importantes de la etapa de análisis, dando énfasis a la especificación de casos de uso y a como detectar objetos y clases relevantes en el problema.

El objetivo del análisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. El AOO, como los métodos de análisis convencionales descritos, forma un modelo de análisis multiparte para satisfacer este objetivo.

El modelo de análisis ilustra información, funcionamiento y comportamiento dentro del contexto de los elementos del modelo de objetos.

Analisis y diseño orientados al objeto es la tecnologia de dotacion logica. Cada objeto representa alguna entidad del interes en el sistema que es modelado, este es caracterizado por su clase, su estado y su comportamiento. Los varios modelos se pueden crear para demostrar la estructura estatica, el comportamiento dinamico y el despliegue runtime de estos objetos de colaboracion. Una de las notaciones para representar estos modelos es el UML ( Lenguaje Unificado de Modelado).

El analisis orientado a objetos aplica objeto-modelar tecnicas para analizar los requisitos funcionales para un sistema. El sistema orientado al objeto elabora los modelos del analisis para producir especificaciones para la puesta en practica.

El Análisis y el Diseño de sistema, tienen como fin estudiar sistemáticamente la operación de ingreso de los datos, el flujo de los mismos y la salida de la información; todo ello dentro del contexto de una empresa en particular.

Gestión de Calidad de Software

El ciclo de vida de un sistema software empieza en el momento en que nace la idea de desarrollar el sistema y acaba cuando el software por alguna u otra razón deja de ser usado.

Entre estos dos momentos el producto software pasa por varias fases: el diseño de alto nivel, el diseño técnico o detallado, el diseño de programa, el diseño de módulo, la codificación, la ejecución de las pruebas finales, la implantación, la explotación y el mantenimiento, y por último su sustitución por otro sistema.

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

La gestión de la calidad es el único instrumento adecuado para evitar un exceso de los gastos por falta de calidad del producto y de los procesos de desarrollo y de mantenimiento, y para poder decidir de forma responsable si un sistema es apto para su uso o no. La gestión, y como parte de ella el control de la calidad, no es exclusivamente la responsabilidad de los que desarrollan un sistema software. Sus clientes, es decir, los usuarios finales, tienen un papel incluso más importante en este proceso. En la situación óptima el equipo de calidad está compuesto por representantes de ambos partidos. Desde el punto de vista de los usuarios la cima de la gestión de la calidad está en la llamada prueba de aceptación, donde la prueba de aceptación se define como aquellas realizadas por los usuarios con carácter previo al paso a producción de una nueva versión del producto. Se trata de pruebas de caja negra en un entorno de preproducción en la que se verifican si las funcionalidades pactadas para la entrega y recogidas en catálogos de requisitos, casos de uso, historias de usuario u otro hito documental, cumplen las expectativas del usuario.

Pruebas de Software

Existen varias metodologías y técnicas para probar software, evaluar prototipos y revaluar la funcionalidad. Todas comparten un objetivo: maximizar la calidad de los productos de software. Pero la prueba en sí misma no mejora la calidad del software. Las pruebas y otros análisis sólo pueden revelar donde hay un problema y la calidad no está asegurada hasta que se han eliminado los problemas notificados.

En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba. Por lo anterior, es común que algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final. Sin embargo, la terminología apropiada para referirse a los diferentes niveles corresponde a la siguientes cuatro (4) clasificaciones que son: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación. En cada uno de estos niveles de prueba, se podrán ejecutar diferentes tipos de prueba tales como: pruebas funcionales, no funcionales, de arquitectura y asociadas el cambio de los productos.

A continuación una breve descripción de cada nivel de prueba:

Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de robustez, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así la capacidad de tratar errores de manera controlada. Adicionalmente, Las pruebas sobre componentes unitarios, suelen denominarse pruebas de módulos o pruebas de clases, siendo la convención definida por el lenguaje de programación la que influye en el término a utilizar. Por último, es importante que toda la funcionalidad de cada componente unitario sea cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar al menos una funcionalidad positiva y una negativa.

Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y consisten en la comprobación de que elementos del software que interactúan entre sí, funcionan de manera correcta.

Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la tercerización de esta responsabilidad. La obligación de este equipo, consiste en la ejecución de actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema fue implementada de acuerdo a los documentos de especificación definidos en el proyecto. Los casos de prueba a diseñar en este nivel de pruebas, deben cubrir los aspectos funcionales y no funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el equipo debe utilizar como bases de prueba entregables tales como: requerimientos iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de usuario final, etc. Por último, es importante que los tipos de pruebas ejecutados en este nivel se desplieguen en un ambiente de pruebas / ambiente de pre-producción cuya infraestructura y arquitectura sea similar al ambiente de producción, evitando en todos los casos utilizar el ambiente real del cliente, debido principalmente, a que pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en otros servicios alojados en este ambiente.

Pruebas de Aceptación: Independientemente de que se haya tercerizado el proceso de pruebas y así la firma responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto de prueba, es indispensable, que el cliente designe a personal que haga parte de los procesos de negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los usuarios finales que participen en este proceso, sean independientes al personal que apoyó el proceso de desarrollo. Cuando las pruebas de aceptación son ejecutadas en instalaciones o ambientes proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando son ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta. En los casos en que las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha son opcionales, pero las pruebas Beta son obligatorias.

También de acuerdo al grado de conocimiento de la estructura interna del sistema bajo prueba se pueden clasificar las pruebas en:

Pruebas de caja blanca (White-Box Testing). Son pruebas estructurales. Conociendo el código y siguiendo su estructura lógica, se pueden diseñar pruebas destinadas a comprobar que el código hace correctamente lo que el diseño de bajo nivel indica y otras que demuestren que no se comporta adecuadamente ante determinadas situaciones. Ejemplos típicos de ello son las pruebas unitarias. Se centran en lo que hay codificado o diseñado a bajo nivel por lo que no es necesario conocer la especificación de requisitos, que por otra parte será difícil de relacionar con partes diseñadas a muy bajo nivel.

Las pruebas de caja negra (Black-Box Testing) son pruebas funcionales. Se parte de los requisitos funcionales, a muy alto nivel, para diseñar pruebas que se aplican sobre el sistema sin necesidad de conocer como está construido por dentro (Caja negra). Las pruebas se aplican sobre el sistema empleando un determinado conjunto de datos de entrada y observando las salidas que se producen para determinar si la función se está desempeñando correctamente por el sistema bajo prueba. Las herramientas básicas son observar la funcionalidad y contrastar con la especificación.

Ejemplos típicos de pruebas de caja negra son la comprobación de valores límite, pruebas de integridad de la base de datos, pruebas de situaciones de excepción, o pruebas de rendimiento del sistema. Presentan una limitación en cuanto a que es prácticamente imposible reproducir todo el espectro por la innumerable cantidad de combinaciones de entrada posibles, agravada por el desconocimiento de la lógica interna.

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

Software Libre (SL)

Software Libre (SL)

El software libre es aquel que una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido libremente. 

Para estudiarlo y modificarlo la distribución del Software Libre debe incluir el código fuente, característica fundamental. Tiene sus bases en una ideología que dice que el software no debe tener dueños, es un asunto de libertad: la gente debería ser libre de usarlo en todas las formas que sean socialmente útiles. 

El software libre suele estar disponible gratuitamente, pero no hay que asociar software libre a software gratuito, o a precio del coste de la distribución a través de otros medios; sin embargo no es obligatorio que sea así y, aunque conserve su carácter de libre, puede ser vendido comercialmente. 

 De esta forma, el movimiento del Software Libre pone lo que es beneficioso para la sociedad por encima de los intereses económicos o políticos. 

El Software Libre ofrece a las personas la posibilidad de utilizar, estudiar, modificar, copiar y redistribuir el software. Para hacer efectivas estas libertades, el código fuente de los programas debe estar disponible. 

Gracias a estas libertades obtenemos muchos beneficios prácticos:

• Podemos ejecutar el software cuando queramos y para lo que queramos.
• Podemos aprender de los programas existentes.
• Podemos mejorarlos. 
• Podemos adaptarlos para que se ajusten a nuestras necesidades. 

Las motivaciones de SL son dos, la primera es la motivación ética abanderada por la Free Software Foundation (FSF). Partidaria del apelativo “libre”: el Software es conocimiento y debe poder difundirse sin trabas. La ocultación de Software es antisocial y la posibilidad de modificar programas es una forma de libertad de expresión; y la segunda es la motivación pragmática abanderada por la Open Source Iniciative (OSI). Partidaria del apelativo “fuente abierta”. Argumenta que el Software de este tipo tiene ventajas técnicas y económicas. 

El SL ha tenido múltiples consecuencias tanto positivas como negativas. Entre las consecuencias positivas tenemos: 

• Transferencia del conocimiento para el desarrollo de los países Subdesarrollados. 
• Contribuye con la reducción de gastos.
• También hay soporte y cursos de entrenamiento y certificación.
• El software comercial ha rebajado el precio de sus programas y los debe rebajar aún más. 

Entre las negativas tenemos:

• El económico. Se argumenta que no se puede obtener mucho dinero de la distribución del SL. Muchos confunden Software Libre con software gratis, lo cual es un error. Este argumento se hace débil, cuando comenzamos a estudiar los diferentes modelos de negocio asociados al SL. 
• La calidad. La falta de financiación, asociada a los mecanismos de desarrollo del SL, podría influir en la calidad de los productos finales. Con el tiempo ha quedado más que demostrado, que las aplicaciones de software libre, son de calidad igual o superior a las de software propietario.
• El Soporte. Debido a que el software no tiene dueño, y pasa de mano en mano, se dice que el soporte, es escaso o inexistente. Esta afirmación, también resulta ser falsa en la mayoría de los casos, ya que los buenos desarrollos de SL, cuentan con un excelente soporte basado en foros de usuarios y desarrolladores, por otra parte, el soporte de aplicaciones de SF se está convirtiendo en un negocio muy lucrativo.

 Algunos de los hechos históricos más relevante a lo largo del tiempo en relación al software libre son: 

En los años 80 se empezó a trabajar para conseguir formalizar el software libre, y la situación comenzó a invertirse. 

En 1984, Richard Stallman abandona el “AI Lab” del MIT para comenzar el proyecto GNU. Esto se debe a su desacuerdo con los contratos de exclusividad y a la no compartición. 

La idea de la Free Software Foundation (FSF) era y es la construcción de un sistema de Software completo, de propósito general, pero completamente libre. El proyecto se llamó GNU (GNU's Not Unix). Las primeras herramientas para GNU fueron un compilador de C (GCC) y un editor de textos (Emacs). El proyecto GNU desarrolla desde hace más de diez años un núcleo para GNU llamado Hurd. 

Para principios de los años 90, GNU sólo necesitaba un núcleo, pero Hurd aún necesitaba mucho tiempo para ser adecuado, así que se plantearon dos proyectos que lo sustituirían temporalmente: BSD y Linux. 

A principios de los 90 BSD consiguió finalmente reescribir todo el código heredado de Unix, y tuvo así un núcleo totalmente libre. 

En Julio de 1991 Linus Torvalds, estudiante finlandés de Informática, anuncia en Internet que quiere implementar un sistema libre similar a Minix. 

En Marzo de 1994 apareció Linux 1.0, la primera versión estable. Durante ese periodo se unieron cientos de desarrolladores a Linux que colaboraron en el núcleo, y adaptaron las herramientas de GNU. 

A mediados de 1992 empiezan a aparecer las primeras distribuciones de Linux, como SLS (ahora Slackware). 

Desde el punto de vista técnico, lo más destacable de la época de los 90 es la aparición de dos grandes proyectos para construir entornos de escritorio: KDE (Octubre 1996) y GNOME (Agosto 1997).

En 1998 se crea la Open Source Iniciative (OSI), que es la organización que abandera el movimiento Open Source.

A principios del 2000 El Software Libre es un serio competidor en el mercado de los servidores, y empieza a hacerse un hueco entre los usuarios con GNOME 2.x, KDE 3.x y OpenOffice.

Mapa Conceptual Software Libre