lunes, 30 de mayo de 2011

Licenciamiento en Software Libre

Licencias de uso del software libre.

Es un contrato por el que el titular de los derechos sobre el software, permite su utilización a otra persona, y determina las condiciones bajo las cuales dicho usuario puede utilizar el programa informático, prohibiciones y límites que debe respetar. 

Las siguientes licencias son calificadas como software libre, y son compatibles con GNU GPL


Las siguientes licencias son software libre, pero no son compatibles con GNU GPL
Netscape Public License (NPL), versions 1.0 and 1.1



Non-Free Software Licenses
Las siguientes licencias no califican como software libre. Al no ser software libre, automáticamente son incompatibles con GNU GPL.



Licenses For Documentation
Las siguientes licencias califican como licencias de documentación libre.



Non-Free Documentation Licenses
Las siguientes licencias no califican como licencias de documentación  libre.




Licenses for Works of Practical Use Besides Software and Documentation
Licencias para obras de uso práctico, además de software y documentación




Licenses for Works of Opinion and Judgment
Licencias para obras de opinión y sentencia



Aspectos legales relacionados con el licenciamiento de Software Libre

En este tema hay mucho qué explicar y en qué profundizar. En primer lugar, se van a dar las definiciones de términos, siglas y lenguaje más utilizados en esta área, con el fin de hacer entendible este resumen, a cualquier lector. Enseguida se van a describir las principales licencias existentes en software libre.

1)    Software libre – Richard Stallman y la FSF (free software foundation) 1984.

Free: En inglés significa libertad y gratuidad. En software libre se refiere a que el software se distribuye bajo una licencia que permite  a los usuarios aprovecharlo libremente.

“Las licencias de software libre son aquellas  que mediante la puesta a disposición del código fuente del programa de ordenador, permiten y aseguran a los usuarios, el ejercicio de las libertades de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software”.

FSF (free software foundation: La Free Software Foundation (FSF), es una organización sin ánimo de lucro cuyo objetivo es promocionar la libertad de los usuarios de ordenadores, y defender los derechos de los usuarios de software libre.

Richard Stallman es el autor de la Licencia GNU.

Copyleft:  Se define como 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 modificada.

GPL (General Public License): Incluye términos de redistribución que no permiten a los redistribuidores añadir a su licencia cualquier restricción adicional a la de la licencia original. Se conoce como copyleft. La licencia GPL permite explícitamente cobrar por la redistribución. El precio está limitado únicamente por las reglas del mercado. 

Las licencias GPL están enmarcadas dentro de las cuatro libertades del software libre:
Libertad 0: Libertad de ejecutar y usar el software para cualquier propósito
Libertad 1: Libertad de estudiar el programa y adaptarlo a sus necesidades
Libertad 2: Libertad de distribuir copias
Libertad 3: Libertad de modificar el programa y liberar las modificaciones al público.

2)    Software de Código abierto. (open Source software) – Erick Raymond, 1998.

El software de código abierto mantiene las libertades fundamentales del software libre, pero no el concepto de copyleft, pues considera que la distribución posterior de obras modificadas debe permanecer flexible y no exigible como lo hace la FSF, la garantía de que la distribución posterior será flexible.

OSI (open source iniciative) – Iniciativa de código abierto.
La OSI es una institución reconocida para la revisión y aprobación de las licencias OSD. La OSI participa activamente en la comunidad de código abierto, en la educación y defensa pública y  en la promoción del conocimiento y la importancia del software no propietario. Los miembros de la junta Directiva de OSI, con frecuencia viajan por el mundo para asistir a conferencias y eventos de código abierto, para reunirse con los desarrolladores y los usuarios, y para discutir con los ejecutivos de los sectores público y privado sobre cómo las tecnologías de código abierto, licencias y modelos  de desarrollo económico, pueden ofrecer ventajas estratégicas.
 

3. Licencias Creative Commons. 

Este tipo de licencias ofrecen algunos derechos a terceras personas bajo ciertas condiciones. “Poner sus obras bajo una licencia Creative Commons, no significa que no tengan copyright”. Hay un total de seis licencias Creative Commons para escoger:
1.Reconocimiento (Attribution): En cualquier explotación de la obra autorizada por la licencia hará falta reconocer la autoría.
2.No Comercial (Non commercial): La explotación de la obra queda limitada a usos no comerciales.
3.Sin obras derivadas (No Derivate Works): La autorización para explotar la obra no incluye la transformación para crear una obra derivada.
4.Compartir Igual (Share alike): La explotación autorizada incluye la creación de obras derivadas siempre que mantengan la misma licencia al ser divulgadas.

Con estas cuatro condiciones combinadas se pueden generar las seis licencias que se pueden escoger:

a) Reconocimiento (by): Se permite cualquier explotación de la obra, incluyendo una finalidad comercial, así como la creación de obras derivadas, la distribución de las cuales también está permitida sin ninguna restricción.
b) Reconocimiento - NoComercial (by-nc): Se permite la generación de obras derivadas siempre que no se haga un uso comercial. Tampoco se puede utilizar la obra original con finalidades comerciales.
c) Reconocimiento - NoComercial - CompartirIgual (by-nc-sa):No se permite un uso comercial de la obra original ni de las posibles obras derivadas, la distribución de las cuales se debe hacer con una licencia igual a la que regula la obra original.
d) Reconocimiento - NoComercial - SinObraDerivada (by-nc-nd): No se permite un uso comercial de la obra original ni la generación de obras derivadas.
e) Reconocimiento - CompartirIgual (by-sa): Se permite el uso comercial de la obra y de las posibles obras derivadas, la distribución de las cuales se debe hacer con una licencia igual a la que regula la obra original.
f) Reconocimiento - SinObraDerivada (by-nd): Se permite el uso comercial de la obra pero no la generación de obras derivadas. 
      
        http://www.fsf.org/
        http://www.gnu.org/



martes, 17 de mayo de 2011

Métricas y Normas.

¿Qué es Métrica 3?
Es una metodología que ofrece a las organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software. Esta metodología fue promovida por el Ministerio de Administraciones Públicas del Gobierno de España con el fin de aplicarla en la Administración Pública de ese país y ésta se realizó basada en las normas ISO/IEC 12207 y ISO/IEC 15504.

Elementos de Métrica 3:
Esta métrica está conformada por una serie de elementos que son los siguientes:
· Procesos
· Interfaces
· Técnicas y Prácticas
· Roles o Perfiles

Procesos involucrados en la Métrica 3:
· Planificación de Sistemas de Información (PSI)
· Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su vez dividido en cinco procesos:   

Estudio de Viabilidad del Sistema (EVS)
Análisis del Sistema de Información (ASI).
      - Diseño del Sistema de Información (DSI).
      - Construcción del Sistema de Información (CSI).
      - Implantación y Aceptación del Sistema (IAS).
      -  Mantenimiento de Sistemas de Información (MSI).
Es importante señalar, que tanto la Métrica 3 como las normas ISO/IEC 12207 se encuentran orientadas establecer parámetros de calidad del proceso de desarrollo de un software determinado.

Interfaces de Métrica 3:
· Gestión de proyectos (GP).
· Seguridad (SEG).
· Aseguramiento de la Calidad (CAL).
· Gestión de la Configuración (GC).

Técnicas de Métrica 3:
· Técnicas de desarrollo (Casos de Uso, Diagramas de Clase, Diagramas de Flujo de Datos, etc).
· Técnicas de gestión de proyectos (Técnicas de estimación, Staffing Size, Planificación, etc)
· Prácticas (Análisis de impacto, Presentaciones, Prototipado, etc).

Perfiles o Roles en Métrica 3:
· Directivo (Comité de Dirección, Directores de Usuarios, etc).
· Jefe de Proyecto (Responsable de Implantación, Responsable de Seguridad, etc).
· Consultor (Consultor Informático, Técnico de Sistemas).
· Analista (Analista, Administrador de Bases de Datos, etc).
· Programador.

Por último, se destaca que MÉTRICA versión 3 puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual, es decir, el Ministerio de Presidencia.


Norma ISO-9126
ISO 9126 es un estándar internacional para la evaluación del Software. Está supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos. El estándar está dividido en cuatro partes las cuales dirigen, respectivamente, lo siguiente: modelo de calidad, métricas externas, métricas internas y calidad en las métricas de uso.
El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1. Dicho estándar ha sido desarrollado en un intento de identificar los atributos clave de calidad para el software. El estándar identifica 6 atributos clave de calidad:

Funcionalidad – El grado en que el software satisface las necesidades indicadas por los siguientes subatributos:
o Idoneidad
o Corrección
o Interoperabilidad
o Conformidad
o Seguridad

Fiabilidad – Cantidad de tiempo que el software está disponible para su uso. Está referido por los siguientes subatributos:
o Madurez
o Tolerancia a fallos
o Facilidad de recuperación

Usabilidad – Grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos:
o Facilidad de comprensión
o Facilidad de aprendizaje
o Operatividad

Eficiencia – Grado en que el software hace óptimo el uso de los recursos del sistema. Está indicado por los siguientes subatributos:
o Tiempo de uso
o Recursos utilizados

Mantenibilidad – Facilidad con que una modificación puede ser realizada. Está indicada por los siguientes subatributos:
o Facilidad de análisis
o Facilidad de cambio
o Estabilidad
o Facilidad de prueba

Portabilidad – La facilidad con que el software puede ser llevado de un entorno a otro. Está referido por los siguientes subatributos:
o Facilidad de instalación
o Facilidad de ajuste
o Facilidad de adaptación al cambio

La garantía de calidad de software es una actividad de protección que se aplica a cada paso del proceso de software. La SQA comprende procedimientos para la aplicación efectiva de métodos y herramientas, revisiones técnicas formales, técnicas y estrategias de pruebas, dispositivos poku-Yoke, procedimientos de control de cambios, procedimientos de garantía de ajuste a los standares y mecanismos de medida e información. Las revisiones del software son una de las actividades más importantes del SQA. Las revisiones sirven como filtro durante las actividades de ingeniería del software, eliminando defectos mientras no son relativamente costosos de encontrar y corregir.

ISO/IEC 14598 
La ISO/IEC 14598 ofrece una visión general, explica la relación entre su serie y el modelo de calidad de la ISO/IEC 9126. Define los términos técnicos utilizados, contiene requisitos generales para la especificación y evaluación de la calidad del software, y clarifica los conceptos generales. Además, provee un marco de trabajo para evaluar la calidad de todos los tipos de productos de software y establece requisitos para métodos de medición y evaluación de los productos de software

Es importante señalar que, la serie de normas ISO/IEC 14598 proporciona un marco de trabajo para evaluar la calidad de todos los tipos de productos de software e indica los requisitos para los métodos de medición y para el proceso de evaluación.
Se verá enseguida que la ISO/IEC 14598 consta de seis partes que describen los requisitos del proceso de evaluación en tres situaciones diferentes:
* Requisitos para desarrolladores
* Requisitos para compradores
* Requisitos para evaluadores
Se puede decir que ISO/IEC 14598, proporciona métodos para medida, valoración y evaluación de calidad del producto de software, pero no describen los métodos para los procesos de evaluación de la producción del software o predicciones del costo.

Este propone las siguientes actividades para los procesos de evaluación:
- Revisión General (ISO/IEC 14598-1)
- Planificación y Administración (ISO/IEC 14598-2)
- Proceso para Desarrolladores (ISO/IEC 14598-3)
- Proceso para Adquisidores (ISO/IEC 14598-4)
- Proceso para Evaluadores (ISO/IEC 14598-5)
- Documentación de Módulos de Evaluación (ISO/IEC 14598-6)

Gestión de calidad y pruebas de software


Según Pressman, la calidad del software 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 espera de todo software desarrollado profesionalmente”.

Aporte profesora María Esther “El modelo de desarrollo del Software Libre facilita el aseguramiento y control de la calidad, dado que el código abierto asegura la transparencia y la trazabilidad del software, el desarrollo colaborativo exige la generación de un código más claro y mejor documentado y los usuarios, al ser tratados como colegas, participan activamente en la especificación, desarrollo y validación del código”.

La calidad de software debe ser tenido en cuenta en cualquier proyecto de software que iniciemos. Debe incluirse un ciclo integral de desarrollo de procesos de control de calidad y pruebas desde el principio del proyecto, de lo contrario, el costo de desarrollo de este proceso posteriormente, será demasiado alto.
El software casi nunca es perfecto, todo proyecto de software tiene como objetivo, producir software con la menor cantidad de errores posible, que cumpla con las expectativas de los usuarios y los requerimientos exigidos.
"El software tiene una medida de 0,150 errores por cada 1000 líneas de código. Si tenemos en cuenta que un producto como OpenOffice.org 1.0 tiene aproximadamente 7 millones de líneas de código, la aritmética es sencilla"

Para asegurar la calidad del software en cualquier proyecto, es importante tener en cuenta los siguientes principios:

- Es imperativo disponer de unos requisitos que detallen el sistema
- Los procesos de calidad deben ser integrados desde  las primeras fases del proyecto
- Quien desarrolle un sistema no debe ser quien prueba su funcionalidad.

¿En qué consiste la gestión de calidad y pruebas del software?
Este proceso de la ingeniería de software consiste en someter al producto de software a un conjunto de pruebas, basadas en prestaciones, respuestas esperadas a determinadas acciones y bajo ciertas condiciones, con la finalidad de determinar la calidad del mismo.

En la ingeniería de software se aplica el checklist, el cual consiste en un listado de procedimientos para la consecución de un objetivo, en este caso, la instalación y correcto funcionamiento de la aplicación a investigar. Además, sirve para ayudar a asegurar la consistencia e integridad en el desarrollo de la tarea, de tal modo, que sea reproducible siguiendo todos los pasos que constituyen el checklist. Es muy utilizado en el aseguramiento de la calidad en ingeniería de software, para comprobar la conformidad de procesos, estandarización de código, prevención de errores y otros.

La calidad de un software, debe ser medida en tres puntos:
a) Durante el proceso de desarrollo.
b) Al obtener el producto de software.
c) Durante el ciclo de vida del software (calidad del servicio).

Entre las normas que rigen la calidad, se encuentran:
a) Para el producto se encuentra la norma ISO-9126.
b) Para la calidad de desarrollo se encuentra la ISO-14598.
c) CMMI for Development (v1.2), está orientado a la mejora de procesos en diferentes niveles de madurez.
d) Moprosoft, programa de México para la Industria de Software, orientado a empresas pequeñas y medianas.

Por otra parte, algunas de las pruebas no funcionales son: las pruebas de rendimiento (performance) y pruebas de carga, pruebas de estabilidad, pruebas de usabilidad, pruebas de seguridad, pruebas de internacionalización y localización y pruebas destructivas.
MOSCA es otro modelo de especificación de la Calidad Sistémica del Software desarrollado en el Laboratorio de Investigación en Sistemas de Información LISI de la Universidad Simón Bolívar , se caracteriza por ser una herramienta que soporta la Administración de la Calidad del Software en sus tres actividades: Aseguramiento de la Calidad, Planeación de la Calidad y Control de la Calidad, al establecer un marco de referencia que permite ubicar en un “nivel establecido” la calidad sistémica de sus productos.

Para tener en cuenta…..
Ley de Linus (Torvalds):
"given enough eyeballs, all bugs are shallow" - Dados suficientes ojos, todos los errores son superficiales. Entre más desarrolladores puedan leer y analizar el código fuente y usuarios utilicen una aplicación, mayor es la probabilidad de que los errores sean encontrados, reportados y finalmente corregidos.

Los peores ‘bug’ (errores informáticos) de la historia:

1. Fallo en la sonda Mariner 1:Un "bug" en el software de vuelo de la sonda Mariner I provocó que, segundos después del lanzamiento de la nave, en julio de 1972, ésta se desviara de su curso preestablecido. Los responsables de la misión se vieron obligados a destruir el cohete cuando se encontraba sobrevolando el Atlántico. La investigación del accidente determinó que el problema estaba en una fórmula escrita a lápiz que luego fue "inadecuadamente" trasladada al lenguaje informático, lo que hizo que el cohete calculara mal la trayectoria que debía seguir.
2. Explosión en un gaseoducto soviético :La mayor explosión registrada en la Tierra por causas no nucleares tuvo su origen en un fallo de programación. Supuestamente, agentes de la CIA colocaron un "bug" en un sistema informático canadiense adquirido por los soviéticos para controlar el gaseoducto Transiberiano. Seguían órdenes de Reagan, que había mandado a sus agentes a sabotear toda la tecnología rusa, colocando "cosas" que permitían manipular a distancia todo tipo de maquinaria y tecnología. Así, en 1982 la CIA decidió sabotear este gaseoducto, pero al activar el "bug" las cosas salieron mucho peor de lo esperado y provocaron la gigantesca explosión.
3. Acelerador médico Therac-25 :El Therac-25 era un acelerador lineal empleado en los hospitales en la década de los 80 para tratar tumores. La máquina emitía radiación de alta energía sobre células cancerosas sin dañar el tejido circundante. Los operarios, con el tiempo y la práctica, conseguían gran velocidad tecleando la secuencia de comandos para iniciar un tratamiento. Pero debido a un fallo de programación, si durante este proceso efectuaban una corrección en menos de ocho segundos, la máquina podía emitir 100 veces más energía de la requerida. A consecuencia de este "bug" murieron al menos cinco pacientes y varias decenas sufrieron los efectos de verse expuestos a una elevada radiación.
4. El 'Gusano de Morris':El primer 'gusano' de Internet nació la tarde del 2 de noviembre de 1988, cuando un estudiante estadounidense, Tappan Morris, liberó un programa creado por él mismo que infectó entre 2.000 y 6.000 ordenadores sólo el primer día, antes de ser rastreado y eliminado. Para que su 'gusano' tuviera efecto, Morris descubrió dos errores en el sistema operativo UNIX, que le permitieron tener acceso no autorizado a miles de ordenadores.
Esto demuestra cuán difícil es el proceso de llevar a cabo una buena gestión de calidad y pruebas sobre el software, además de la importancia que tiene, por el impacto que puede tener a nivel social, pudiendo causar cualquier omisión o falla no detectada, pérdidas materiales y económicas, y peor aún, pérdidas humanas.
http://www.lisi.usb.ve/

lunes, 9 de mayo de 2011

UML: Unified Modeling Language. Lenguaje Unificado de Modelado.

Entre los lenguajes de modelado más utilizados se destaca UML, un estándar usado para describir sistemas lógicos, incluyendo procesos y funciones del sistema, así como esquemas de bases de datos y objetos reutilizables. Presenta un conjunto de notaciones y diagramas estandarizados para modelar sistemas, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Anteriormente se manejaban diversas notaciones y métodos para el modelado, ahora se cuenta con una única notación.

Este estándar ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas 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.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.

UML, sus vistas:
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.

Qué no es UML.
UML no es un método de desarrollo. Nos indica cómo pasar del análisis al diseño y de este al código. No son una serie de pasos que lleva a producir código a partir de unas especificaciones.

UML al no ser un método de desarrollo es independiente del ciclo de desarrollo que se vaya a seguir, puede encajar en un tradicional ciclo en cascada, o en un evolutivo ciclo en espiral o incluso en los métodos ágiles de desarrollo.

Un poco de historia.
UML Se ha convertido en el estándar de facto de la industria, debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a objetos más populares: Grady Booch, Ivar Jacobson y Jim Rumbaugh.
Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la cual basar la construcción de sus herramientas CASE.
En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa: Booch, OMT y OOSE. UML ha puesto fin a las llamadas “guerras de métodos” que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.

Bibliografía
http://www.ingenierosoftware.com
Orallo Hernandez, E. (n.d.). El Lenguaje Unificado de Modelado (UML). Retrieved from http://www.disca.upv.es/enheror/pdf/ActaUML.PDF