jueves, 10 de julio de 2008

Lo que publico hoy no me pertenece, le agradezco al Prof. Julio Hernan Morales, colega y gran amigo, a quien aprecio por lo que es ....
También motiva esta publicación a una cuantas solicitudes de cibernautas que me han preguntado si tengo esquemas de desarrollo de trabajos de investigación en el área de informatica, para todos aquí me permito darles este material.

METODOLOGIA PARA PROYECTOS DE GRADO
PROPOSITO.
Un Proyecto de Grado debe constituirse no solo en el mecanismo que facilite la “Obtención de un título, representado en un cartón”, sino en un PROYECTO DE VIDA, del cual cada uno pueda sentirse orgulloso. Debe ser el resultado de un proceso juicioso de Investigación que permita “ La identificación y descripción detallada de los aspectos técnicos, administrativos, de control y de personal, necesarios para resolver un problema”[1]. Debe tener como objetivo “ Presentar y describir detalladamente lo que se va a investigar, la base teórica, conceptual, los componentes metodológicos y los recursos humanos, técnicos y económicos, necesarios para realizar la Investigación”[2].
Por ésta razón y conscientes de su importancia, Asesores Científicos y Metodológicos del Programa, proponen una metodología consecuente con estos aspectos, donde cada investigador (Estudiante y Tutor), comprometan su esfuerzo, conocimientos y entusiasmo en construir una solución real y efectiva a una necesidad específica. Será aplicable de acuerdo a las características del proyecto y a los puntos de vista del investigador.

FASES DEL PROYECTO

FASE I.
1 ASPECTOS DE LA INVESTIGACION.
1.1 DESCRIPCION DEL PROBLEMA.
Es el punto de partida de todo proyecto. Se origina a partir de una necesidad no satisfecha ya sea en el plano teórico, humano, administrativo, político, científico, etc.. Consiste en mostrar los hechos pertinentes o aspectos que requieren de una solución. Es la identificación de las características del problema en términos concretos y explícitos. Debe ser expresado en términos claros. Es relacionarlo con situaciones, personas, instituciones o elementos que lo originan:
§ Grupos de población afectados
§ Areas geográficas afectadas.
§ Factores involucrados
§ Magnitud del problema.
§ Frecuencia
§ Personas o instituciones involucradas en el asunto a tratar.
1.2 JUSTIFICACION DEL PROYECTO DE INVESTIGACION.
Es presentar los argumentos por los cuales es imprescindible realizar el proyecto. La claridad y precisión de ellos permitirá visualizar con objetividad las metas que se pretender alcanzar. Debe reflejar la importancia de solucionar el problema, las razones por las cuales la realización del proyecto será vital para resolver el problema planteado. Se tendrán en cuenta (las que apliquen):
1.2.1 Razones Sociales.
1.2.2 Razones jurídicas.
1.2.3 Razones Económicas.
1.2.4 Razones Técnicas
1.2.5 Razones Organizacionales
1.2.6 Razones Metodológicas.
1.3 DELIMITACION.
Es identificar los límites y restricciones dentro de los cuales van a moverse el proyecto o la investigación.
1.3.1 Espacial. Descripción de la ubicación en donde se va a desarrollar el proyecto. Ente Físico en su entorno. Brevemente, no de manera detallada, una reseña histórica de la Institución, población o sector donde se realizará la investigación. Es necesario incluir a la UMB, como gestora y facilitadora del proyecto. Mostrar dónde va a ser aplicable el producto de la investigación.
1.3.2 Cronológica. Indica el tiempo que el proyecto requiere para ser realizado en todas sus Fases. Consiste en dividir la realización del proyecto en etapas, con su correspondiente descripción de actividades y el tiempo de duración de cada una de ellas debidamente calculado, empleando herramientas que permitan visualizar los avances alcanzados. Ejemplo de una de ellas es PROJECT, con sus opciones: Diagramas de Gannt y Pert.
1.3.3 Conceptual. Muestra los aspectos que cubre y que no cubre la investigación. Corresponde al alcance del proyecto.
1.3.4 Financiera. Se calculan los recursos requeridos, el presupuesto que se va a invertir en el proyecto. Es importante considerar los aspectos de Factibilidad económica, el VPN (Valor presente neto), el punto de equilibrio.
1.3.5 Metodológica. Expresar cuál va a ser la metodología propia a utilizar. Para Sistemas, debe estar basada en alguna metodología tal como: CVDS (Ciclo de vida del desarrollo de sistemas), empleando herramientas específicas como UML (UNIFIED MODELING LANGUAJE), RAD (), RUP, etc..
1.4 OBJETIVOS.
Son los resultados observables que se obtendrán para resolver el problema formulado. “ Son especificaciones del objeto desde el punto de vista del nivel de conocimiento que se quiere alcanzar en la investigación”.[3] Su formulación debe comprender resultados concretos en el desarrollo del proyecto; el alcance de estos objetivos debe estar dentro de las posibilidades del investigador.
1.4.1 General. Tiene como fin señalar el resultado que se desea obtener de la investigación y del proyecto o TEG. Su redacción debe emplear verbos en infinitivo y ser alcanzable en el tiempo y con los recursos asignados.
1.4.2 Específicos. Tienen como propósito mostrar los resultados o metas parciales que deben ejecutarse y concluirse para obtener el logro del objetivo general. También deben enunciarse con verbos en infinitivo. Cada objetivo específico debe incluir un solo logro, indicando lo que realmente se desea alcanzar.
1.5 PROPOSITO.
Muestra los beneficios a nivel de la comunidad, la sociedad y la economía que se obtendrán del proyecto. Es el PARA QUE se va a hacer el proyecto o la investigación.
FASE II.
2 MARCO TEORICO.
Contextualiza, sustenta y explica teóricamente el problema de investigación o del proyecto. Es una descripción detallada de cada uno de los elementos esenciales de la teoría, de tal manera que la formulación del problema y su solución sean una deducción lógica de ella. Tiene como función principal prevenir errores que se han cometido en otros proyectos o investigaciones anteriores, orientar y ampliar el horizonte de la investigación, evitando desviaciones. Un buen marco teórico no es aquel que contiene muchas páginas, sino el que trata con profundidad únicamente los aspectos que se relacionan con el problema y que vincula lógica y coherentemente los conceptos y proposiciones existentes en estudios anteriores con el problema planteado. No se trata de hacer una sumatoria de conceptos, sino que permita la construcción de nuevas teorías sobre la solución del problema de investigación; como mínimo debe contemplar los siguientes pasos:
2.1 ANTECEDENTES.
2.1.1 HISTORICOS.
Debe mostrar la evolución del objeto en estudio, revisando aspectos puntuales de él.
2.1.2 LEGALES.
Normatividad y Jurisprudencia con respecto al objeto de estudio. Relacionar los Decretos, leyes, normas y demás aspectos legales Y jurídicos que tengan relación con el objeto de estudio.
2.1.3 INVESTIGATIVOS.
Mostrar brevemente otras investigaciones, trabajos, proyectos, desarrollos similares o relacionados con el proyecto u objeto de estudio.
2.2 BASES TEORICAS.
Corresponde a la revisión literaria, bibliográfica, relevante, con el objeto de estudio. Es necesario aclarar que se trata de una síntesis conceptual y no de un tratado producto de una “transcripción textual” de los conceptos.
2.3 TEORIAS GENERICAS BASADAS EN INGENIERIA.
Corresponde a toda la narrativa literaria técnica de ingeniería, de las herramientas a utilizar en el proyecto ( Bases de Datos, Redes Neuronales, Plataformas, etc.).
2.4 CONSTRUCCION DEL MARCO CONCEPTUAL.
Es la elaboración teórica de la posible solución del problema. En él aparecen el esquema conceptual, las definiciones propias del investigador de acuerdo a su criterio, explicando y prediciendo cuál será el estado de su proyecto..
2.4.1 METAS A ALCANZAR.
Con todos los conocimientos adquiridos a esta etapa del proyecto, el Alumno esta en capacidad de identificar las metas que desea conseguir a corto, mediano y largo plazo, de manera más concreta y específica.
2.4.2 PRINCIPIOS.
Son las características que debe reunir el producto final y que garanticen su operatividad (Integridad referencial, consistencia, argumental, etc., Portabilidad, Calidad, Recursividad, etc.).
2.4.3 ENFOQUE.
Dirección que se le va a dar al proceso en el desarrollo: puntual, integral, global.
2.4.4 NECESIDADES A SATISFACER.
El desarrollo el proyecto debe solucionar una serie de inconvenientes, reflejados en su momento en la descripción del problema. Es mostrar el beneficio que producirá el proyecto en términos de suplir unas necesidades. Ej.: En un proyecto de control de cartera, un requerimiento a cubrir es el Estado de Cuenta de cada usuario.
2.4.5 PRODUCTOS DEL MODELO.
En este aparte se idean los productos a obtener y que estarán disponibles al terminar el proyecto. Ej.: Para el mismo caso de Cartera, el Liquidador de Vencimientos.
2.4.6 SERVICIO.
Se refleja la utilidad que va a prestar el desarrollo. Ej.: Control de fechas de vencimiento de cada cuota en Cartera, Identificador de sanciones por mora, etc.
2.4.7 FUNCIONES.
Conjunto de procesos individuales que se deben ejecutar para obtener un servicio. Ej.: Sysdate, rangos de fechas, rangos de números, límites, etc.).
2.4.8 CONTROLES.
Medidas de seguridad que va a tener el modelo a desarrollar.
2.4.9 OBSERVACIONES.
Aquí se documentarán otros aspectos relevantes para el modelo, que no han podido reflejarse en otras instancias.
2.5 DEFINICION DE TERMINOS BASICOS.
Breve Glosario con la definición de palabras claves utilizadas permanentemente en el contenido del proyecto.
NOTA. Es importante tener en cuenta que para modelos, prototipos, sistemas de información y software en general, no se requiere del planteamiento de Hipótesis, aspecto relevante en estudios e investigaciones.
FASE III.
3 DISEÑO METODOLOGICO.
Tiene como fin establecer cómo se llevará a cabo la investigación, diseñando detalladamente la estrategia para obtener la información, puntualizando las actividades necesarias para darle respuesta a los objetivos planteados. Es la parte del proceso de investigación que hace referencia a los procedimientos que deben utilizarse para lograr en forma precisa y exacta el objetivo que persigue el proyecto de investigación.
3.1 TIPO DE INVESTIGACION.
Para proyectos de ingeniería, normalmente puede hablarse de Investigación Cuantitativa ya que parte de un problema y unos objetivos bien definidos por el investigador, utiliza técnicas estadísticas muy estructuradas para la recolección y el análisis de la información. En esta clase de investigación se pueden mencionar diferentes tipos[4]:
· DESCRIPTIVA. Su objetivo es referir e interpretar minuciosamente lo observado, describir el estado, las características, factores y procedimientos del objeto en estudio. Ej.: Sistematización del área de cartera. Interpretación de lo que es, "Comprende la descripción, registro, análisis e interpretación de la naturaleza actual, composición o procesos de los fenómenos. El enfoque se hace sobre conclusiones dominantes, o sobre una persona, grupo o cosa, que conduce a interpretar realidades de hecho. se efectúa cuando se desea describir, en todos sus componentes principales, una realidad.
· EXPLORATORIA. Es considerada como el primer acercamiento científico a un problema. Se utiliza cuando éste aún no ha sido abordado o no ha sido suficientemente estudiado y las condiciones existentes no son aún determinantes.
· EXPLICATIVA. Es aquella que tiene relación causal; no sólo persigue describir o acercarse a un problema, sino que intenta encontrar las causas del mismo.
Es conveniente mencionar el otro tipo de investigación que es la Cualitativa que se refiere a los estudios sobre el quehacer cotidiano de las personas o de grupos pequeños. En este tipo de investigación interesa lo que la gente dice, piensa, siente o hace. Su función puede ser la de describir o la de generar una teoría a partir de los datos obtenidos. Los investigadores desarrollan conceptos, intelecciones y comprensiones y comprensiones, partiendo de los datos y no recogiendo datos para evaluar modelos, hipótesis o teorías preconcebidas. Es de índole interpretativa.
3.2 ANALISIS.
3.2.1 DESCRIPCION DEL SISTEMA ACTUAL.
Permite establecer cómo funciona el objeto en estudio actualmente, teniendo en cuenta: las condiciones prevalecientes, puntos de vista de implicados, actividades, procesos, tendencias, requerimientos, eventos que ocurren en el ciclo de vida del objeto en estudio; se describe a través de diagramas que apliquen a cada caso (Diagramas de Contexto, DFD, Eventos, etc..). Este conocimiento debe ser adquirido con base en observación, entrevistas, investigación del entorno y demás.
3.2.2 DIAGNOSTICO DE LA SITUACION ACTUAL.
Es vislumbrar claramente el problema planteado al inicio del proyecto. De él emanarán los requerimientos del sistema propuesto. (Técnicos, de datos, de usuario, de conectividad, etc.).
3.2.3 METODOLOGÍAS PARA EL ANALISIS.
Con los años se han propuesto muchos métodos para el modelado del análisis. Algunos de ellos son:
3.2.3.1 Análisis Estructurado[5]. Es una actividad de construcción de modelos, que tiene como centro el Diccionario de Datos y entre otras las siguientes actividades:
§ Diagrama de Flujo de Datos
§ Modelo Entidad – Relación
§ Especificaciones de Procesos
§ Especificaciones de Control
3.2.3.2 Análisis Orientado a Objetos. Permiten al Ingeniero de Software modelar un problema a través de la representación de objetos, atributos y operaciones como las componentes primarias del modelado. Existen una gran variedad de métodos de Análisis orientado a objetos[6]:
§ El Método de Booch
§ El Método de Coad y Yourdon.
§ El Método de Jacobson
§ El Método de Rumbaugh
§ El Método de Wirfs – Brock
§ Unified Modeling Languaje. UML. Lenguaje Unificado de Modelado.
Todos poseen un conjunto de características comunes:
§ Representación de clases o jerarquías de clases
§ Creación de modelos de Objeto – Relación
§ Derivación de Modelos Objeto – Comportamiento.
3.2.4 ALTERNATIVAS DE SOLUCION, EVALUACION Y SELECCIÓN DE LA MEJOR.
El problema tendrá una serie de soluciones, que serán analizadas una a una, en todos sus aspectos: económicos, técnicos, humanos, legales y demás, con el propósito de optar por la mejor. Esta selección estará sustentada por escrito, para desde este instante asumir la responsabilidad de todo el proceso adelantado hasta esta parte y el que se ejecutará para lograr el resultado final.
3.3 DISEÑO
El Diseño se ha descrito como un proceso multifase en el que se sintetizan representaciones de la estructura de datos, estructura del programa, estructura de la interfaz y detalles procedimentales desde los requisitos de la información. Existen diversos Métodos de diseño, todos aplicables y válidos, dependiendo específicamente del enfoque del proyecto.
§ Diseño Estructural
§ El Diseño Orientado a Objetos (DOO)
3.3.1 DISEÑO LOGICO.
3.3.1.1 DISEÑO DE PROCESOS
Se hará énfasis en cambios que se presenten a todos los niveles: procesos, normas, procedimientos, aspectos Organizacionales, etc., empleando metodologías apropiadas (Gráficas).
3.3.1.2 DISEÑO DE DATOS.
Facilita establecer los datos que va a procesar el sistema, su composición, atributos, donde van a residir, sus relaciones. Puede ser expresado por medio de:
3.3.1.2.1 Modelo Entidad – Relación. (E – R). Entidades y sus Relaciones.
3.3.1.2.2 Modelo de Datos. (Modelo E – R normalizado mínimo hasta 3FN).
3.3.1.2.3 Diseño de Tablas. (Estructura, llaves).
3.3.1.2.4 Diseño Semántico. (Reglas del negocio. Es la condición semántica de los datos). Ej.: Para realizar un pago a Proveedor, es regla, que exista una factura o una cuenta de cobro.
3.3.1.3 DISEÑO ARQUITECTONICO.
Define la relación entre los principales elementos estructurales del programa
3.3.1.3.1 Modelo Funcional. Módulos que van a conformar el software teniendo en cuenta sus encadenamientos. Es la estructura jerárquica de los componentes del programa (módulos), la manera de interactuar de estos componentes y la estructura de los datos usados por estos componentes.
3.3.1.3.2 Especificaciones de Programas. Debe nombrarse cada programa, relacionando: Objetivo, Entrada, Proceso, Salida, tabla o proceso que afecta, etc.
3.3.1.3.3 Diseño de Interfaz de Usuario. Es la interacción entre el usuario y el aplicativo. Debe tenerse en cuenta tanto para las entradas como para las salidas.
3.3.1.3.4 Diseño de Ayudas. Es necesario recordar que las ayudas estén disponibles para todas las funciones del sistema y en todo momento durante la interacción con el sistema. (Incluir Manuales).
3.3.2 DISEÑO FISICO.
3.3.2.1 DISEÑO DE LA BASE DE DATOS.
Por tratarse del lugar en el que reposará la información, su diseño es vital para el buen uso de los datos.
3.3.2.1.1 Aspectos físicos de la Base de Datos. Longitudes, Rangos (dominios), índices, secuencias.
3.3.2.1.2 Procedimientos. Trigger, Storage Procedure,
3.3.2.2 Pantallas e informes.
3.3.3 DISEÑO DE SEGURIDAD Y CONTROLES.
Todo proyecto debe ofrecer seguridad y controles, garantizando de esta manera Integridad en la información.
3.3.3.1 De la Base de Datos
3.3.3.2 Matriz de Funciones Vs. Usuarios
3.3.3.3 Niveles de seguridad
3.3.3.4 Roles.
3.3.3.5 Perfiles.
3.3.3.6 Permisos
FASE IV.
4 ANALISIS DE RESULTADOS Y CONCLUSIONES.
4.1 CODIFICACION DE PROGRAMAS.
4.2 BANCOS DE PRUEBA.
4.2.1 Pruebas de Función
4.2.2 Pruebas Modulares
4.2.3 Pruebas del Sistema
4.2.4 Prueba de Interfaz
4.2.5 Prueba de Documentación y de ayuda
4.2.6 Prueba de Seguridad y Control
4.2.7 Prueba de Calidad
4.3 Informe de Pruebas (Resultados)
4.4 Aceptación (cartas de aprobación)
4.5 Análisis de Resultados
4.6 Conclusiones.
4.7 Recomendaciones
BIBLIOGRAFIA. En lo posible hacer una breve descripción del tema del libro consultado. Cuando sea una dirección de Internet, describir el tema del sitio consultado.
MANUALES DE USUARIO Y TECNICO.
1. De usuario.
§ Presentación del Manual
§ Explicación General de la aplicación o del sistema
§ Descripción de teclas de función a utilizar
§ Por cada módulo, explicar todas y cada una de las pantallas, opciones, botones, listas de valores
§ Descripción de informes, con una muestra real de cada uno.
§ Explicación de parámetros del sistema
§ Explicación de la estructura de ayudas.
§ Glosario
2. Técnico.
§ Presentación del Manual
§ Características de máquina
§ Estructura o procedimiento técnico de instalación, haciendo énfasis en que todos deben ser booteables, documentando éstas estrategias.
Autoboteo de Código. Adjuntar código con sus principales comentarios.
Autoboteo de Utilitarios del sistema. Se deben colocar iconos, comandos que se utilizan paso a paso para producir el objeto ejecutable.
§ Copias de seguridad
§ Entrada al programa
§ Estructura del árbol general del programa (Diagrama estructural)
§ Especificaciones funcionales de los programas
§ Estructura de Uso de la base de datos. Programación que permite alimentar la base de datos a través de pantallas de captura (Formas)
§ Consulta y extracción de resultados, informes todos representados por código. Cuando la base de datos es creada con una herramienta diferente a las formas con que se alimentan los reportes, debe enunciarse la herramienta de conexión (OBDC (a la base de datos), ASP (a la web), PHP (funciones)).
§ Estructura de conectividad cuando el sistema es distribuido o cuando tiene salida a Internet. Enunciar herramientas y describir paso a paso.
§ Mensajes de error del sistema
RESUMEN. Apoyo para Jurados. Ver Guía Investigaciones.



[1] Tamayo, 1995, 26.
[2] Metodología de la Investigación: Propuesta, Anteproyecto y Proyecto”. Hector Daniel Lerma.
[3] BRIONES, (92).
[4] Metodología de la Investigación. Hector Daniel Lerma (2.001)
[5] Ingeniería de Software. Un Enfoque Práctico. Roger Pressman.
[6] Ingeniería de Software. Un Enfoque Práctico. Roger Pressman.

martes, 1 de julio de 2008

mas Software libre

Esta es la tercera entrega

El usuario final

Están los “olvIdate”...

* OlvIdate de los monopolios (verdadera competencia, mejores produc­tos, mejores servicios).

* OlvIdate de la “fiabilidad” del productor (el futuro lo asegura la acepta­cion del producto, y la disposicion del fuente).

* OlvIdate de tomar decisiones con pocos elementos (puedes probar el software en su entorno real a coste prácticamente cero).

* OlvIdate de depender de la estrategia de tus proveedores.

El usuario final

...ylos“¿quétalsi...?”

* ¿Qué tal si pudieras adaptar/personalizar el producto como quieras? ¿Qué tal si pusieras “estar a la ültima” a bajo coste?.

* ¿Qué tal si pudieras arreglar los problemas (o pagar para que los arre­glen?

* ¿Qué tal si pudieras decidir sobre la evolución futura del producto?

* ¿Qué tal si pudieras contratar la integración de los dos mejores pro­ductos en el entorno que te interesa?

*

El usuario final

Gran parte del control pasa al usuario

(frente al productor de software).

El desarrollador/productor de software

El software libre cambia las reglas del juego.

* Puedes competir siendo pequeño.

* Es mucho más fácil adquirir tecnolog´ıa punta (y más barato).

* Te puedes aprovechar del trabajo de tu competencia (ojo: también tu competencia del tuyo).

* Si lo haces bien, puedes conseguir, a bajo coste, la colaboración de mucha gente.

* El canal de distribución es mucho más barato, y global.

* Es posible convertirte en aplicación de referencia mucho más fácil.

El desarrollador/productor de software

¿Y de dónde saco el dinero?

* El mejor conocimiento sobre el programa lo tiene su desarrollador. Si se cuida la imagen, el desarrollador es el “punto más visible”. Desarrollos a med ida, mod ificaciones, personal izaciones.

* Soporte “a lo grande” (corrección de erratas, acceso preferente a nue­vas versiones, nuevas caracter´ısticas, etc.)

Si hay gente que quiere software, y está dispuesto a pagarlo,
algún desarrollador/productor se beneficiará...

El integrador

¡Bienvenido al para´ıso!

* Todos los productos libres están a tu disposición (¡y sin preocuparte de licencias propietarias!).

* Si los productos no “encajan”, puedes “limarlos” (tienes el código fuen­te, puedes conseguir interoperabilidad).

* Puedes integrar “trozos” de productos, o productos enteros, o lo que sea.

* No más cajas negras: las tripas de todo son transparentes.

Puedes construir sobre el trabajo de otros, en igualdad de
condiciones con esos otros.

Mantenimiento y servicios

El disponer del fuente lo cambia todo.

* Estás en las mismas condiciones que el productor. Competencia en el negocio del mantenimiento.

* El valor añadido de los servicios es mucho más apreciado (el coste del programa es bajo).

* El conocimiento del estado del arte es muy importante (es bueno tener relación con los proyectos libres).

* Negocios nuevos: consejo sobre versiones y combinaciones de pro­gramas, información sobre nuevos desarrollos, gestión de proyectos libres.

* Este es actualmente el negocio más claro.

Principales obstáculos

El software libre está demostrando estar aqu´ı para quedarse, pero pueden presentarse problemas:

* Técnicas FUD (miedo, desconocimiento, duda): hasta ahora han mos­trado no ser muy problemáticas.

* “Disolución” (sistemas que pueden confundirse con el software libre): división de la comunidad, pérdida de las ventajas del modelo.

* Desconocimiento (pérdida de visión): ¿por qué es interesante el soft­ware libre?

* Impedimentos legales: por ejemplo, patentes software. Y abrá más...

¿Hay conclusiones?

Aün hay pocos casos para estar seguros de por dónde saldrá todo esto.

Pero hay muchas buenas perspectivas.

* ¿Eres competitivo?: en este modelo tienes muchas ventajas. ¿Eres pequeño?: en este modelo tienes muchas ventajas. Se está experimentando con nuevos modelos de negocio.

* Hace falta mucha innovación, imaginación... pero también conoci­miento del entorno.

* Nunca ha sido tan importante tener información buena, y de primera mano.

* Aün quedan problemas por resolver... ¿o son oportunidades de negocio?

* El software libre muestra ser un modelo económica y técnicamente viable.

* Detrás de él hay motivaciones técnicas, económicas y éticas.

* Es muy importante conocer el mundo en que nos movemos...

* El futuro depende, en gran parte de nosotros (como profesionales, como clientes, como empresarios,...).

*

Este es uno de esos raros momentos en los que toda una
industria puede estar cambiando de paradigma.

Algunas URLs

Free Software Foundation: http://www.fsf.org

Open Source Initiative: http://www.opensource.org

Grupo de trabajo de la Comisión Europea sobre software libre: http://eu.conecta.it

Curso de doctorado sobre software libre: http://curso-sobre.berlios.de

Open Sources (O’Reilly) http://www.openresources.com/documents/open-sources

BarraPunto: http://barrapunto.com