LICENCIAS DE SOFTWARE LIBRE

Continuando con el tema de los aspectos legales del software libre, aquí dejo un resumen de los licenciamientos asociados al tema.

Licencias de software libre robustas: contienen una cláusula que obliga que las obras derivadas o modificaciones que se realicen al software original se deben licenciar bajo los mismos términos y condiciones de la licencia original. Son firmes en el uso del copyleft. A continuación se presenta el ejemplo más representativo de este tipo de licencia:

a.- GNU GPL: (Licencia Pública General de GNU) Está orientada principalmente a proteger las 4 libertades: (1) ejecución y uso, (2) estudio y adaptación, (3) distribución de copias y modificación y (4) su liberación. Al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se la denomina contrato de licencia o acuerdo de licencia. La GPL incluye términos de distribución que no permiten a los redistribuidores añadir a su licencia cualquier restricción adicional (a las de la licencia original), ni al software original, ni a obras derivadas. Es la licencia más usada en el mundo del software libre con un 75% del código libre publicado.

Licencias de código abierto robustas débiles (mixtas): Son aquellas con copyleft  débil o híbridas, contiene una cláusula que obliga a que las modificaciones que se realicen en el software original se deban licenciar bajo los mismos términos o condiciones de la licencia original, pero que las obras derivadas que se puedan realizar de él puedan ser licenciadas bajo otros términos y condiciones distintas. Algunos ejemplos son:

a.- Mozilla Public License: Cumple completamente con la definición de software de código abierto de la Open Source Initiative (OSI) y con las cuatro libertades del software libre enunciadas por la Free Software Foundation (FSF). Sin embargo la MPL deja abierto el camino a una posible reutilización de forma comercial no libre del software, si el usuario así lo desea, sin restringir la reutilización del código ni el re-licenciamiento bajo la misma licencia. Aunque el uso principal de la MPL es servir como licencia de control para el navegador Mozilla y el software relacionado con él, esta licencia es ampliamente utilizada por desarrolladores y programadores que quieren liberar su código.

Tiene algunas restricciones complejas que la hacen incompatible con la GNU GPL

b.- LGPL (Lesser General Public Licence): La licencia menor es igual en condiciones y restricciones a la GPL común, con la diferencia que permite enlazar a software privativo, su uso sólo es recomendado en casos puntuales y estratégicos. Esta licencia permisiva se aplica a cualquier programa o trabajo que contenga una nota puesta por el propietario de los derechos del trabajo estableciendo que su trabajo puede ser distribuido bajo los términos de esta "GPL General Public License".

c.- Common Public License:  Se traduce como Licencias Pública Común, tiene el objetivo declarado de apoyar y fomentar el desarrollo colaborativo de software de código abierto al tiempo que conserva la capacidad de utilizar el contenido CPL con software licenciado bajo otras licencias, incluyendo muchas licencias privativas. Se diferencia de la GPL porque carece de compatibilidad con ambas versiones de la GPL ya que  tiene una sección "Cláusula de opción de ley" en la sección 7, que restringe disputas legales para un determinado tribunal. Otra fuente de incompatibilidad son los requisitos del diferente copyleft. La Free Software Foundation y la Open Source Initiative han aprobado los términos de licencia de la CPL.

Licencias de código abierto permisivas: Son aquellas licencias que permiten crear una obra derivada sin que esta tenga obligación de protección alguna, entre estas se encuentran:

a.- Apache software license: Existen tres versiones de la licencia Apache (1.0, 1.1. y 2.0) siendo la 2.0 la más empleada. Las dos primeras versiones carecen de Copyleft. La última versión es considerada una licencia de Software Libre. Incorpora ciertas condiciones extra relacionadas con patentes: exige incluir un permiso de uso de patentes por parte del autor/poseedor de las patentes y además puede rescindirse la licencia por problemas de patentes. Estas características la hacen incompatible con la GNU GPL 2, pero posiblemente no con la GNU GPL 3 en desarrollo, ya que esta contempla el problema de las patentes desde una perspectiva similar.

b.- BSD license: Este tipo de licencias se caracteriza por no tener copyleft. Considera que si el software es libre no debe imponer ninguna restricción en su distribución aunque esto signifique que cualquiera use el software para su propio beneficio y no comparta el código. Uno de los aspectos por lo que las licencias  BSD no eran consideradas libres por GNU era su cláusula de publicidad (también conocida como “4-clause”) que obligaban a hacer mención a la Universidad de Barkeley, lo cual era una restricción adicional. En el año 1999, esta cláusula fue eliminada y a partir de allí la licencia BSD se fragmento en dos tipos: las que incluían la “4-clause” y las que no. Hoy en día muchos proyectos grandes usan licencias del tipo BSD o inspiradas en su filosofía.

Fuentes:

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-ii/

http://es.wikipedia.org/wiki/Licencia_de_software

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-i/

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-ii/

http://es.wikipedia.org/wiki/Copyleft   

http://es.wikipedia.org/wiki/Common_Public_License

ASPECTOS LEGALES DEL SOFTWARE LIBRE

Las licencias de software libre son las que van a garantizar la ejecución de las libertades de ejecutar, usar, estudiar, adaptar, distribuir copiar, modificar y liberar las modificaciones del software al público. Para la protección de la libertad del software libre, Richard Stallman funda la Free Software Foundation (FSF), para la cual no es suficiente con cumplir las libertades básicas sino que las distribuciones ulteriores del programa continúen con las mismas libertades. Esta fundación establece que el único software realmente libre es aquel que se distribuye con una licencia GPL (con copyleft). Lo que diferencia el software libre de la FSF es precisamente el término de copyleft, ya que existe software libre que se distribuye con otras licencias, denominándolo código abierto (open sourse). El llamado código abierto intenta ofrecer una perspectiva sobre el software libre más pragmática y orientada al mundo empresarial y se le dio este nombre para diferenciarlo del software libre de la FSF que está relacionado con el copyleft. Por lo tanto este se caracteriza por también respetar las cuatro libertades del software libre pero no poseer copyleft. En definitiva queda claro que lo esencial en estas licencias es la distribución del código fuente del programa y que a excepción de la clausula de copyleft las discrepancias entre ambas no son legales sino de postura.

Algunas definiciones:

Copyleft: Es una práctica al ejercer el derecho de autor que consiste en permitir la libre distribución de copias y versiones modificadas de una obra u otro trabajo, exigiendo que los mismos derechos sean preservados en las versiones modificadas. Esta condición particular, establece la imposibilidad legal de capturar el software libre, modificarlo y privatizarlo. Es un término establecido por la Free Software Foundation (FSF).

Dominio público: Es todo aquel software sin copyright, es el modo más simple de hacer un programa libre. Esto permite que la gente comparta el programa y sus mejoras, si así lo desean. Pero también permite a quien no quiera cooperar, convertir el programa en software privativo. Pueden hacer cambios y distribuir el resultado como un producto privativo. Las personas que reciban el programa en su forma modificada no poseen la libertad que el autor original les dio debido a que el intermediario se la ha quitado.

INCompatibilidad de licencias: la incompatibilidad entre licencias se da cuando dos software distintos poseen requisitos contradictorios imposibilitando combinar partes de los mismos para crear uno nuevo. La proliferación de licencias muchas veces resulta problemático ya que conlleva a agravar la incompatibilidad y volver engorroso el proceso de licenciamiento del Software Libre, además de incrementar el número de textos legales que deberían leer los desarrolladores y distribuidores de Software Libre.

Las licencias software libre pueden ser: robustas, robustas débiles y permisivas. Estas las explicaré en una próxima publicación.

Fuentes:

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-ii/

http://es.wikipedia.org/wiki/Licencia_de_software

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-i/

http://www.maestrosdelweb.com/editorial/licencias-libres-de-software-ii/

http://es.wikipedia.org/wiki/Copyleft   

 http://es.wikipedia.org/wiki/Common_Public_License

CONTROL DE CALIDAD DEL SOFTWARE

No es más que la realización de pruebas para detectar defectos, tratando de minimizar o eliminar la publicación de software defectuoso y  mejorando el resultado en diferentes iteraciones del ciclo de entrega – certificación.

“Es la concordancia con los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente”.

En las fuentes consultadas hacen referencia a  3 puntos importantes en definición de calidad de software:

1- Los requerimientos del software son los fundamentos desde los que se mide la calidad.
2- Los estándares específicos definen un conjunto de criterios de desarrollo que guían la forma de aplicación de la ingeniería de software.

3- Existen requerimientos implícitos que no se mencionan

La medición de la calidad del software puede hacerse desde tres grandes dimensiones:

1.-Pruebas de calidad: que pueden ser funcionales, de rendimientos, de estrés, de integración, de usabilidad entre otras.

2.-Gestión de calidad: subdividida en la planificación de la calidad, aseguramiento de la calidad y control de la calidad

3.-Modelos de calidad: CMMI, normas ISO / IEC , mosca , entre otros.

Un producto de alta calidad requiere menos mantenimiento y facilita tanto el desarrollo como el mantenimiento de la productividad. Con la medición de la calidad se pueden lograr estos objetivos. En lo que se refiere al mantenimiento, la medición de la calidad del software ayuda a identificar problemas de confiabilidad y a mejorar las técnicas para identificar las necesidades de mantenimiento.

La garantía de calidad de software engloba:

1.-Métodos y herramientas de análisis, diseño, codificación y prueba.

2.-Revisiones y técnicas formales que se aplican en cada fase de la ingeniería de software.

3.-Una estrategia de prueba multiescalada.

4.-El control de la documentación del software y de los cambios efectuados.

5.-Un procedimiento que asegure un ajuste a los estándares de desarrollo
6.-Mecanismos a medida y de información

Fuente:

http://www.ub.edu.ar/catedras/ingenieria/ing_software/ubftecwwwdfd/calidadsw/calidad.htm

http://es.wikipedia.org/wiki/Calidad_de_software

Mapa Conceptual sobre la ingeniería del Software

Anexo coloco un mapa conceptual en donde resumí  un poco los principales elementos asociados al desarrollo de la ingeniería del software, pasando desde sus paradigmas, principios y metodologías hasta la medición de su calidad.

Ciclo de vida del Software

Se llama ciclo de vida a las diferentes etapas por las que debe pasar el software desde su inicio (en donde es concebido)  hasta el final de su desarrollo en donde se encuentra listo para usarse.

Las etapas o fases suelen ser llamadas de diferentes maneras y su orden y presencia va a depender del tipo de  modelo acordado para desarrollar.

Las fases suelen ser:

1.-Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar.

2.-Diseño: requisitos generales y precisos de la arquitectura de la aplicación.

3.-Programación  o desarrollo (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño.

4.- Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones.

5.- Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada.

6.- Implementación: es la puesta en marcha del sistema

7.-Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

Entre los modelos de desarrollo de software más conocidos se encuentran:

-Modelo de cascada

-Modelo incremental

-Modelo evolutivo

-Modelo en espiral

Entre otros

Fuentes:

http://es.kioskea.net/contents/genie-logiciel/cycle-de-vie.php3

http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20-%2001.pdf

Lenguaje Unificado de Modelado (UML)

Es un lenguaje de modelado de sistemas de software, que permite capturar las partes esenciales del mismo.

“UML sirve para el modelado completo de sistemas complejos, tanto en el diseño de los sistemas software como para la arquitectura hardware donde se ejecuten.”

Entre los objetivos de UML expuestos por (Hernández) se encuentran:

Visualizar: Permite expresar de una forma gráfica un sistema de forma que otro lo puede entender.

Especificar: Permite especificar cuáles son las características de un sistema antes de su construcción.

Construir: A partir de los modelos especificados se pueden construir los sistemas diseñados.

Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas, estos diagramas son:

• Diagrama de casos de uso.

• Diagrama de clases.

• Diagrama de objetos.

• Diagrama de secuencia.

• Diagrama de colaboración.

• Diagrama de estados.

• Diagrama de actividades.

• Diagrama de componentes.

• Diagrama de despliegue.

Beneficios de la utilización de UML

-Produce un aumento en la calidad del desarrollo. 

-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.

-Brinda la posibilidad de obtener un "plano" del sistema. 

-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.

-Permite especificar la estructura y el comportamiento del sistema y comunicarlo a todos los integrantes del proyecto. 

-Permite dimensionar mejor los riesgos de un proyecto tener un mejor rendimiento antes de construir el sistema.

-Facilita la documentación de las decisiones de la arquitectura del proyecto. 

-Ofrece mayor rigurosidad en la especificación.

-Permite realizar una verificación y validación del modelo realizado.

-Se pueden automatizar determinados procesos y permite generar código a partir de los modelos y viceversa.

Anexo les dejo este video que habla un poco de lo que ES y  NO es UML, así como de sus historia y la definición de los diagramas de clases

Fuente:

http://www.cientec.com/analisis/ana-uml.html

http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html

http://www.disca.upv.es/enheror/pdf/ActaUML.PDF

http://www.youtube.com/watch?v=XBrUv-rcsBM&feature=related

EVOLUCIÓN DE LA INGENIERÍA DEL SOFTWARE

La ingeniería del software, en comparación con otras ramas de la ingeniería aún se encuentra muy joven, en los tiempos actuales aún se está buscando una forma clara de definirla o trabajarla y la búsqueda de estándares que lleven a un mejor perfeccionamiento en el desarrollo del software. De ahí las continuas interrogantes de considerarla ingeniería o no. Algunos autores consideran que sí, que aún se está en la etapa de establecimiento de bases, otros por el contrario no la califican como tal por falta de técnicas y conocimientos generales que se apliquen en el desarrollo del software.

Como disciplina surge en el año 1968 a raíz de la llamada “crisis del software”, de la cual muchos autores consideran que todavía no se ha salido. Este ha evolucionado con respecto a métodos, lenguajes (de alto y bajo nivel), paradigmas en donde se ha pasado de modelo procedimental al funcional, de este al orientado a objetos y más recientemente el orientado a servicios. En los últimos años el software ha mostrado un claro desarrollo de lo que ha sido los procesos y las herramientas a privilegiar a los individuos y los procesos, ayudado por la masificación del conocimiento y la democracia tecnológica Se ha evolucionado de una programación sin métodos, que era vista como un arte, sin planificación, en donde el software era diseñado a medida para cada aplicación y en donde el oficio de programación se aprendía normalmente por ensayo y error a una programación estructurada, donde se consideraba el retorno dentro de la programación, el paso de la creación del prototipo, a una reducción de las expectativas, a una ingeniería del software basada en componentes y un sinfín de conocimientos que aún se siguen probando para tratar de llegar a una estandarización en la medida de lo posible en la ingeniería del Software.

            Casallas (2007) en su artículo ¿Aún en crisis? expone una reflexión acerca de la crisis, que según la autora, aún vive el desarrollo del software, pudiéndose sentir en la cantidad de proyectos que fallan, que sobrepasan los costos y los tiempos estimados. Se plantean diferentes ideas para desmentir mitos en la ingeniería del software, como son: el ver los proyectos de ingeniería del software de forma similar a como se definen proyectos de otras ingenierías. Mitos referentes a los requerimientos de sistemas, el diseño, los planes detallados del proyecto y las personas que trabajan en el mismo. Establece como el desarrollo en ciclos incrementales permite proponer soluciones a estos problemas que se han convertido en mitos dentro del área. Entender los proyectos del desarrollo de software como proyectos de aprendizaje. Es obvio como la escritora realiza una  crítica a los métodos de programar-corregir que aún siguen siendo muy aplicados en la actualidad.

Fuentes:

http://www.acis.org.co/fileadmin/Revista_102/columnista.pdf