Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this document? Why not share!

Implementacion de software libre

on

  • 472 views

 

Statistics

Views

Total Views
472
Views on SlideShare
472
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Implementacion de software libre Implementacion de software libre Document Transcript

  • Implantación, proyectos y empresas de software libre Amadeu Albós Raya Óscar David Sánchez Jiménez P08/M2104/00604
  • © FUOC • P08/M2104/00604 Implantación, proyectos y empresas de software libre Índice Introducción.......................................................................................... 7 Objetivos................................................................................................. 9 1. Introducción a la implantación de sistemas basados en software libre.................................................................................. 11 1.1. Conceptos básicos ..................................................................... 11 1.1.1. Definición ...................................................................... 11 1.1.2. El plan estratégico de la organización ........................... 12 1.1.3. Origen de la implantación de sistemas ......................... 13 1.1.4. Recursos de un proyecto de implantación de sistemas .......................................................................... 14 1.1.5. Las principales etapas de un proyecto de implantación de sistemas .............................................. 15 1.1.6. La viabilidad y la evaluación del proyecto .................... 17 1.1.7. Metodología del proyecto .............................................. 18 1.2. Tipología de proyectos .............................................................. 19 1.2.1. Clasificación por ámbito ............................................... 19 1.2.2. Clasificación por objetivo de los requerimientos .......... 22 1.3. Los sistemas basados en software libre ..................................... 26 1.4. Gestión de proyectos en software libre .................................... 28 1.4.1. Gestión del alcance ....................................................... 28 1.4.2. Gestión del tiempo ........................................................ 29 1.4.3. Gestión de la integración .............................................. 32 1.4.4. Gestión del coste ........................................................... 33 1.4.5. Gestión de la calidad ..................................................... 33 1.4.6. Gestión de recursos humanos ....................................... 34 1.4.7. Gestión de la comunicación .......................................... 34 1.4.8. Gestión de riesgos .......................................................... 35 1.4.9. Gestión de suministros .................................................. 36 2. El proyecto de software libre..................................................... 37 2.1. Ciclo de vida ............................................................................. 37 2.1.1. El proyecto ..................................................................... 38 2.1.2. Las etapas ....................................................................... 40 2.1.3. La ejecución ................................................................... 41 2.1.4. Los resultados ................................................................ 42 2.2. Estudio de la situación actual ................................................... 44 2.2.1. Identificación del sistema .............................................. 45 2.2.2. Desarrollo del caso de estudio ....................................... 45 2.2.3. Evaluación final ............................................................. 47
  • © FUOC • P08/M2104/00604 Implantación, proyectos y empresas de software libre 2.3. Estudio de los requisitos de la implantación ............................ 48 2.3.1. Identificación y definición ........................................... 50 2.3.2. Especificación y estructuración ..................................... 51 2.3.3. Verificación .................................................................... 52 2.3.4. Validación ...................................................................... 53 2.3.5. Evaluación final ............................................................. 54 2.4. Análisis de las soluciones en software libre ............................. 56 2.4.1. Búsqueda de las soluciones .......................................... 57 2.4.2. Análisis y valoración de los candidatos ......................... 59 2.4.3. Evaluación final ............................................................. 61 2.5. Formalización de la propuesta .................................................. 63 2.5.1. Preparación de la propuesta .......................................... 65 2.5.2. Diseño de la propuesta .................................................. 66 2.5.3. Presentación de la propuesta ......................................... 68 2.5.4. Evaluación final ............................................................. 69 2.6. Desarrollo .................................................................................. 70 2.6.1. Dotación de recursos ..................................................... 72 2.6.2. Configuración y/o desarrollo de software ..................... 73 2.6.3. Evaluación final ............................................................. 75 2.7. Implantación y migración ........................................................ 77 2.7.1. Tipos de migración ........................................................ 78 2.7.2. Estrategias de migración ................................................ 79 2.7.3. Inventario de hardware y software ................................ 81 2.7.4. Diagrama de red y diagrama de estructura .................... 83 2.7.5. Ejecución de la migración ............................................. 85 2.7.6. Evaluación de la migración ........................................... 87 2.7.7. Migración de los servicios de un sistema ...................... 88 2.8. Formación, comunicación y soporte al usuario ....................... 98 2.8.1. Formación ...................................................................... 99 2.8.2. Introducción del software libre ..................................... 100 2.8.3. Comunicación del proyecto .......................................... 101 2.8.4. Sistema de soporte al usuario ........................................ 102 3. La empresa del software libre.................................................... 104 3.1. Modelos de negocio .................................................................. 105 3.1.1. Desarrollo ....................................................................... 107 3.1.2. Consultoría .................................................................... 109 3.1.3. Instalación e integración ............................................... 111 3.1.4. Migración de sistemas ................................................... 113 3.1.5. Administración y mantenimiento de sistemas .............. 114 3.1.6. Soporte y formación ...................................................... 115 3.2. Plan de empresa ........................................................................ 117 3.2.1. Resumen ejecutivo ......................................................... 119 3.2.2. Introducción .................................................................. 120 3.2.3. Descripción del negocio ................................................ 122 3.2.4. Organización de la producción ..................................... 122 3.2.5. Organización interna y recursos humanos .................... 124
  • © FUOC • P08/M2104/00604 Implantación, proyectos y empresas de software libre 3.2.6. Estudio de mercado ....................................................... 125 3.2.7. Plan de marketing ......................................................... 128 3.2.8. Análisis económico-finaciero ......................................... 130 3.2.9. Forma legal .................................................................... 131 3.2.10.Gestión de riesgos .......................................................... 132 3.2.11.Resumen y evaluación ................................................... 132 3.2.12.Plan de empresa y software libre ................................... 133 3.3. Producción de software libre .................................................... 133 3.3.1. Creación y presentación del proyecto ........................... 135 3.3.2. Infraestructura ................................................................ 138 3.3.3. Organización de la comunidad ..................................... 142 3.3.4. Desarrollo ....................................................................... 144 3.3.5. Releasing y packaging....................................................... 147 3.3.6. Elección de licencias ...................................................... 150 Resumen.................................................................................................. 151 Glosario................................................................................................... 153 Bibliografía............................................................................................ 155 Anexo....................................................................................................... 156
  • © FUOC • P08/M2104/00604 7 Implantación, proyectos y empresas de software libre Introducción En este módulo nos adentraremos en la metodología propia de la implanta- ción de sistemas basados en software libre en organizaciones y escenarios ge- néricos, estableciendo las principales particularidades que guían el proyecto y su desarrollo. En la actualidad, la tecnología se posiciona como factor estratégico dentro de la organización, ya sea pública o privada, ya sea de pequeño tamaño, medio o grande. La implicación de la tecnología en todos los procesos funcionales y operativos de la organización relaciona fuertemente su estado de funciona- miento con la producción de la organización, por lo que hay que monitorizar sistemáticamente la eficiencia y la eficacia del sistema con el objetivo de con- trolar el rendimiento frente a la evolución de las necesidades estratégicas de la organización. En este sentido, la implantación de sistemas no se puede dejar al azar o a la conveniencia de factores irrelevantes para la organización, ya que los resul- tados pueden ser imprevisibles y tener consecuencias de diferente magnitud para la organización. Por lo tanto, se establece la necesidad de proceder a la implantación de un sistema con el rigor y la metodología propias de los ámbi- tos científicos y tecnológicos, que establezcan un marco de apoyo que ofrezca garantías para asumir la gestión de la complejidad, el desarrollo del proyecto y la gestión de los riesgos inherentes tanto a la tecnología como al proceso de implantación del sistema. El objetivo central de este módulo es ofrecer una visión amplia y detallada de los principales procesos relacionados con la implantación de sistemas basados en software libre, tanto desde un ámbito genérico o abstracto, como desde una perspectiva especializada en las características de la gestión funcional y opera- tiva del proyecto ligado a la implantación del sistema, o bien considerando el negocio del software libre como método válido y viable de empresa lucrativa. Todos ellos requieren ser afrontados con una gestión metódica y rigurosa que permita por una parte abordar satisfactoriamente la complejidad de solucionar la problemática concreta del proyecto de implantación de sistemas, y por otra parte, mantener controlados todos los riesgos potenciales que puedan hacer fracasar el proyecto de alguna manera concreta, ya sea de forma prematura o bien cuando el sistema ya se encuentra en explotación, ambas situaciones con consecuencias importantes tanto para la organización, como para sus usuarios. Los contenidos de este módulo se estructuran en tres unidades, que presentan progresivamente los conceptos teóricos más importantes del proceso de im- plantación de un sistema en una organización. En este sentido, los apartados
  • © FUOC • P08/M2104/00604 8 Implantación, proyectos y empresas de software libre exponen la implantación de sistemas desde la perspectiva del software libre, analizando las principales características que conducen a garantizar el éxito del proyecto, tanto desde una perspectiva de gestión del proyecto como tal, como de la implantación del software libre como negocio lucrativo. Seguida- mente, se presenta un breve resumen de las principales características de cada una de las unidades de este módulo. El primer apartado, "Introducción a la implantación de sistemas", se dedica a presentar de manera general la implantación de sistemas y las particularidades del software libre. Se define la implantación de sistemas como una actuación consecuente a la estrategia de la organización, detallando los diferentes orí- genes que desencadenan la implantación, las principales etapas del proceso, así como una clasificación de las principales tipologías en función del ámbito del proyecto y de su objetivo. Se presentan las particularidades del software libre, su repercusión en la implantación de sistemas, y la gestión funcional del proyecto en términos de alcance, tiempo, integración, coste, calidad, recursos humanos, comunicación y riesgos. El segundo apartado, "El proyecto de software libre", se dedica a presentar de manera exhaustiva el proyecto de implantación de software libre desde un punto de vista metodológico. Se define el ciclo de vida del proyecto, sus prin- cipales características, repercusiones, y relación con los objetivos. Se presentan detalladamente las etapas de un proyecto de implantación: estudio de la situa- ción actual, estudio de las incidencias en la implantación, análisis de las solu- ciones en software libre, formalización de la propuesta, desarrollo, implanta- ción y migración, y finalmente, formación, comunicación y apoyo al usuario. Se define y se presenta con detalle cada una de las etapas en relación con la consecución de sus objetivos particulares y globales. El tercer apartado, "La empresa del software libre", se dedica a presentar de ma- nera exhaustiva la empresa basada en el software libre, como alternativa válida y viable en venta de copias de software. Se presentan los principales modelos de negocio relacionados con el software libre, basados principalmente en la producción y venta de servicios complementarios. Finalmente, se presentan de manera exhaustiva las características del plan de empresa del software libre, en el cual se detallan aspectos como la definición, los objetivos, el alcance, la organización, los recursos humanos y materiales, la producción, la evolución de los productos, el seguimiento y control de calidad, las garantías y el apoyo al usuario, la economía, la financiación y el estudio de viabilidad del proyecto. Esperamos que la formalización conceptual, metodológica y práctica de los principales aspectos ligados al proyecto de implantación de sistemas basados en software libre os permita entender la necesidad y la importancia tanto del proceso, como de las actuaciones que hay que llevar a cabo para garantizar la consecución de los objetivos estratégicos del proyecto.
  • © FUOC • P08/M2104/00604 9 Implantación, proyectos y empresas de software libre Objetivos Los objetivos de este módulo siguiente son los siguientes: 1. Conocer los conceptos fundamentales de la implantación de sistemas ba- sados en software libre. 2. Saber identificar los diferentes tipos de proyectos de implantación de sis- temas basados en software libre. 3. Familiarizarse con las áreas de gestión de proyectos y sus particularidades aplicadas al software libre. 4. Conocer los elementos principales de un proyecto de software libre. 5. Conocer las fases del ciclo de vida de un proyecto de software libre. 6. Aprender a preparar una propuesta de proyecto de software libre. 7. Conocer en detalle las características de un proyecto de migración a soft- ware libre. 8. Aprender a planificar y ejecutar un proyecto de migración a software libre. 9. Conocer los modelos de negocio utilizados por las empresas de software libre. 10. Familiarizarse con los elementos principales de un plan de empresa o ne- gocio. 11. Aprender a crear un plan de empresa o negocio basado en software libre. 12. Conocer las características principales de la producción de software libre y sus particularidades.
  • © FUOC • P08/M2104/00604 11 Implantación, proyectos y empresas de software libre 1. Introducción a la implantación de sistemas basados en software libre Este primer módulo de la asignatura de Implantación de sistemas de software libre proporciona las bases para conocer los principales conceptos implicados en la implantación de sistemas en general, y su aplicación al software libre en particular. El módulo se inicia con un repaso de los conceptos básicos de los proyectos de implantación de sistemas, con la caracterización de las diferentes fases del proceso desde un punto de vista metodológico y funcional y el análisis de la estrecha relación entre los objetivos estratégicos de la organización y el pro- yecto de implantación. Después, se presenta una clasificación de los tipos de proyectos de implanta- ción más habituales, indicando las principales características y diferencias en- tre ellos y analizando detenidamente las implicaciones en los objetivos del proyecto y en su desarrollo. Una vez se han revisado los conceptos básicos de la implantación de sistemas y los diferentes tipos de proyectos que incluye, se presentan las particularidades de la implantación de sistemas en software libre. Se analizarán los principales factores que influyen en el proyecto y las ventajas y los inconvenientes de la implantación al utilizar software libre. Finalmente, se repasarán los conceptos básicos de la gestión de proyectos y se ampliarán los modelos clásicos para adecuarlos a las particularidades de las implantaciones basadas en software libre. 1.1. Conceptos básicos En este primer apartado repasaremos los conceptos básicos de la implantación de sistemas, desde su definición conceptual hasta las principales fases que la constituyen, sin olvidar los aspectos metodológicos, estratégicos y organiza- cionales. 1.1.1. Definición Históricamente, la implantación de sistemas siempre ha estado estrechamente ligada a la evolución de la tecnología y su difusión popular. De hecho, si se caracteriza el concepto de manera global, cualquier innovación, tecnológica o no, que se quiera difundir fuera del ámbito estricto de sus creadores requiere seguir un proceso de implantación.
  • © FUOC • P08/M2104/00604 12 Implantación, proyectos y empresas de software libre El hecho de corresponder a una implantación tecnológica implica la conside- ración que debe prestarse a algunos aspectos esenciales, como el impacto en la organización y en los usuarios directos, pero también en los usuarios indi- rectos y en los clientes, por ejemplo. Además, actualmente se considera la tec- nología (entendida desde un punto de vista global y genérico) como un factor decisivo en la evolución competitiva de la organización.. En este sentido, la implantación de sistemas es el proceso por el cual se instauran una o más novedades tecnológicas en una organización, como resultado de una actuación que deriva de su plan estratégico. De acuerdo con esta definición, la implantación de sistemas tecnológicos de- riva de una voluntad estratégica de la organización para alcanzar nuevos hitos, el objetivo de los cuales puede ser muy diverso en función del ámbito de la misma organización. Se puede ilustrar este concepto con dos ejemplos de ámbitos diferentes: • Una empresa, en tanto que organización con ánimo de lucro, puede ac- tuar sobre la tecnología que utiliza con el objetivo de mejorar su competi- tividad y así optar a obtener más cuota de mercado, puesto que así puede ofrecer un producto más innovador o adecuado a nuevas demandas. • Una administración pública, en tanto que organización sin ánimo de lu- cro, puede actuar sobre la tecnología a la cual tiene acceso la región que administra, con el objetivo de ofrecer herramientas competitivas para mi- nimizar la fractura digital y desarrollar la economía en este sector. 1.1.2. El plan estratégico de la organización En el anterior apartado se ha hecho referencia al plan estratégico de la organi- zación y a la importancia de su papel en la implantación de sistemas. El plan estratégico de la organización es un conjunto de propuestas que definen los objetivos o tendencias de la organización en el futuro. Acos- tumbra a ser quinquenal, y tiene que desarrollarse posteriormente en las diferentes áreas o departamentos funcionales de la organización. El objetivo principal del plan es minimizar los riesgos y maximizar los resul- tados de la implantación, mediante el establecimiento de tendencias reales, asequibles y mesurables, fruto de la relación entre la organización y el ámbito en el cual actúa.
  • © FUOC • P08/M2104/00604 13 Implantación, proyectos y empresas de software libre Muchas veces, se utiliza el análisis DAFO 1 como herramienta de diagnóstico de la situación actual de la organización, que concreta en una sola tabla los principales factores que influyen en el funcionamiento estructural de la orga- nización en su entorno, en un momento dado. Si se considera que el sistema que se tiene que implantar debe responder a las necesidades actuales y futuras de la organización, se muestra la importancia del vínculo entre el plan estratégico de la organización y el proyecto de im- plantación. El plan estratégico de la organización evoluciona con el tiempo, adaptándo- la dinámicamente a los cambios del entorno en el cual actúa. De la misma manera, el sistema de la organización tiene que evolucionar con los cambios estratégicos y tiene que concluir algunas de las actuaciones emprendidas con un nuevo proyecto de implantación de sistemas. 1.1.3. Origen de la implantación de sistemas En los párrafos anteriores hemos visto el vínculo existente entre el proyecto de implantación y el plan estratégico de la organización. Una organización no pone en marcha un proyecto de implantación sin haber determinado que es necesario llevarlo a cabo para su estrategia particular. Así pues, la implantación de un sistema requiere haber constatado ca- rencias en el sistema actual de la organización, aunque también puede ser el objetivo de una implantación en organizaciones de nueva crea- ción o sin posicionamiento tecnológico previo. A grandes rasgos, se pueden considerar cuatro orígenes genéricos que pueden desencadenar una nueva implantación de sistemas: • Detección￿de￿problemas: puede haber casos diversos de mal funciona- miento del sistema actual, lo que compromete el trabajo habitual de los usuarios y la fiabilidad del propio sistema. En estos casos, el plan estratégico se ve afectado principalmente por la pérdida de rendimiento y eficiencia de la organización. Un ejemplo de esta situación podrían ser los errores de programación que comporten cálculos inexactos, errores de acceso o el bloqueo del sistema. • Evolución￿del￿sistema: se trata de situaciones de obsolescencia funcional del sistema actual, lo que compromete el funcionamiento de la organiza- ción por falta de funcionalidades adecuadas a las crecientes incidencias en la organización. (1) DAFO es la sigla de debilidades, amenazas, fortalezas y oportunida- des. En inglés, SWOT (strengths, weaknesses, opportunities, threats).
  • © FUOC • P08/M2104/00604 14 Implantación, proyectos y empresas de software libre En estos casos, el plan estratégico se ve afectado por la pérdida de eficacia de la organización. Un ejemplo de esta situación podría ser la necesidad de ampliar las funcionalidades ante un cambio de legislación. • Mejora￿del￿sistema: se trata de situaciones de obsolescencia estructural del sistema actual, lo que compromete el funcionamiento de la organización por falta de rendimiento de la plataforma del sistema actual. En estos casos, el plan estratégico se ve afectado por la pérdida de rendi- miento y eficiencia de la organización. Un ejemplo de esta situación po- dría ser la falta de integración a nuevos sistemas operativos o hardware diverso. • Nueva￿actuación￿estratégica: encontramos las posibles actualizaciones, modificaciones o novedades del plan estratégico de la organización que no son cubiertas por el sistema actual. En estos casos, el plan estratégico se ve afectado por la pérdida de eficacia de la organización. Un ejemplo de esta situación podría ser la ampliación de los servicios ofrecidos o del mercado objetivo. La lista de posibles orígenes presentada en los párrafos anteriores no es exhaus- tiva, pero explica las principales razones plausibles que pueden desencadenar una implantación. Asimismo, los diferentes casos no son excluyentes los unos de los otros, sino que su coincidencia puede depender en gran medida de la evolución de la propia organización y de su sistema. 1.1.4. Recursos de un proyecto de implantación de sistemas Habitualmente, una vez se ha detectado la necesidad de actuar sobre el siste- ma actual para adecuarlo al plan estratégico de la organización, se dota de re- cursos al nuevo proyecto de implantación de sistemas. Los recursos se suelen traducir inicialmente en disponibilidad horaria de una o más personas para dedicarse al proyecto, con la repercusión económica que implica tal hecho en el funcionamiento habitual de la organización (insourcing 2 ). (2) El término insourcing hace refe- rencia a la delegación o produc- ción interna de un proceso. Algunas organizaciones prefieren dejar esta tarea a profesionales externos (sub- contratación o outsourcing 3 ) por cuestiones de objetividad funcional, de capa- cidad de producción o de dedicación temporal. En estas circunstancias, la de- dicación temporal de la organización en el proyecto no se anula completa- mente, sólo disminuye en la medida en que aumenta la dedicación externa, ya que tanto la organización como el profesional externo se necesitan mutua- mente con el fin de completar el proyecto con éxito. (3) El término subcontratación hace referencia a la delegación o pro- ducción externa de un proceso.
  • © FUOC • P08/M2104/00604 15 Implantación, proyectos y empresas de software libre Uno de los puntos importantes del proyecto de implantación, independiente- mente del formato final de ejecución, es la creación del comité supervisor o de seguimiento del proyecto (comité ejecutivo en algunas organizaciones). Este comité es el encargado de velar por una ejecución metodológica del proyecto y por un avance del mismo adecuado, progresivo y sostenido en el tiempo. Normalmente, el comité de supervisión está formado por personas de las di- ferentes áreas afectadas por la implantación, principalmente directivos y jefes de departamento. Si la organización hace uso de profesionales externos para gestionar la implantación, éstos también forman parte del comité. Aunque la dedicación de la mayoría de personas involucradas en el comité es parcial, suele haber al menos un miembro con plena dedicación al proyecto, con el objetivo de hacer el seguimiento exhaustivo. El rol de los recursos en la implantación de un sistema es doblemente impor- tante: • Por una parte, porque de la asignación de los recursos humanos dependerá la cantidad y la calidad en el análisis y diseño de implantación del sistema. • Por otra parte, porque de la asignación de recursos materiales dependerá la cantidad y la calidad del sistema a implantar. En cualquier caso, la dotación de recursos en un proyecto de implantación de sistemas tiene una traducción económica directa para la organización. 1.1.5. Las principales etapas de un proyecto de implantación de sistemas Como ya se ha comentado anteriormente, el proyecto de implantación de sis- temas es un proceso metodológico que hay que abordar para ajustar el sistema al plan estratégico. Este proceso se tiene que llevar a cabo con el suficiente cuidado y dedicación para garantizar el éxito del proyecto. Desde una perspectiva genérica, se pueden considerar cuatro grandes fases en el proceso de implantación de sistemas: análisis del sistema actual, diseño del nuevo sistema, desarrollo e implantación del sistema. Análisis￿del￿sistema￿actual Todo proyecto de implantación se inicia con el estudio y análisis del estado actual de la organización en los términos que prefigura la actuación estratégi- ca. Se pueden identificar dos situaciones iniciales diferentes:
  • © FUOC • P08/M2104/00604 16 Implantación, proyectos y empresas de software libre • Si la organización dispone de un sistema implantado, se evalúan las ca- racterísticas recopilando la información y la estructura de los elementos que influyen en la actuación estratégica. El objetivo será crear un marco abstracto de adecuación del sistema a la nueva estrategia. • Si la organización no dispone de un sistema implantado (o es de nueva creación), hay que evaluar las características del entorno de actuación que son objeto del ámbito estratégico de funcionamiento de la organización. Habrá que crear un marco abstracto de objetivos que se tendrán que al- canzar con el proyecto de implantación. En cualquier caso, esta etapa define y determina la problemática a la cual se enfrentará el proyecto de implantación, con la selección de los diferentes ob- jetivos de la actuación estratégica. Se evalúan aspectos como el historial del sistema, la estructura y funcionamiento o la evolución de las incidencias y el volumen de trabajo a lo largo del tiempo. Muchos de estos resultados se pre- sentan en forma de gráficos o diagramas. Esta etapa finaliza con la presentación de las conclusiones del estudio y análisis del estado actual, en las que se valora la idoneidad del sistema para afrontar los nuevos retos estratégicos. Diseño￿del￿nuevo￿sistema Una vez se ha evaluado la situación inicial de la organización y se han defi- nido los principales puntos de actuación estratégicos, y después de recibir la confirmación del seguimiento por parte del comité ejecutivo del proyecto, se inicia el diseño del nuevo sistema. Esta etapa empieza con el análisis exhaustivo de las incidencias que tiene que resolver la nueva implantación de acuerdo con las actuaciones estratégicas de- finidas. A partir de estas incidencias surgirán diferentes soluciones o alterna- tivas a implantar que habrá que analizar individualmente para determinar la idoneidad, los costes, las ventajas y los inconvenientes, tanto tangibles como intangibles. En función del tipo de proyecto y de actuación estratégica, esta valoración se extiende a un periodo quinquenal. La elección de la solución tiene que ser metodológica y objetiva, buscando maximizar las ventajas y minimizar los inconvenientes, tanto de la implan- tación de la solución como de su funcionamiento habitual. Algunos criterios decisorios pueden relacionarse con la extensión de la actuación, el rendimien- to, el equipo requerido, los requisitos que cubre, el soporte del proveedor, la disponibilidad tanto del equipo como del soporte o el mantenimiento nece- sario a lo largo del tiempo. Desarrollo￿del￿nuevo￿sistema
  • © FUOC • P08/M2104/00604 17 Implantación, proyectos y empresas de software libre Después de recibir la confirmación del seguimiento del proyecto por parte del comité de supervisión, se inicia el desarrollo del nuevo sistema. El desarrollo del sistema o la adaptación de las soluciones propuestas sigue el ciclo de vida más adecuado al objeto del proyecto, alguno de los cuales ha sido estudiado en otras asignaturas. Al final de esta etapa se obtiene un sistema preparado para ser implantado en la organización que da solución a las incidencias estratégicas observadas en la etapa anterior. Implantación￿del￿sistema Cuando se dispone del nuevo sistema, se inicia la fase de implantación, que consiste en la puesta en marcha del sistema dentro de la organización. En esta fase se finaliza la adecuación y la integración del nuevo sistema en el entorno real. Forma parte de esta fase la formación de los usuarios, las pruebas piloto y de integración del sistema con los usuarios finales y la conversión y liberación final del nuevo sistema. En caso de que la organización disponga de un sistema implantado, se tiene que considerar además la migración entre el antiguo sistema y el nuevo. La migración consiste en la transferencia del estado actual del sistema en funcio- namiento al nuevo sistema. Normalmente, el traspaso de datos es la tarea más importante de la migración, ya que la transferencia no tiene que impactar en el funcionamiento habitual de la organización. Al final de esta etapa se obtiene la implantación definitiva del nuevo sistema, la migración de los datos y la formación de los usuarios. Es decir, se ha com- pletado la instauración de los elementos necesarios para hacer frente a la ac- tuación estratégica que se había definido inicialmente. Aunque con la implantación del sistema se cierra una parte importante del proyecto de implantación, el mantenimiento y la constante evaluación de la viabilidad del sistema continúan activos como en todo proyecto, especialmen- te si se considera la nueva implantación como factor estratégico para la com- petitividad de la organización. 1.1.6. La viabilidad y la evaluación del proyecto En el apartado anterior se han descrito globalmente las principales fases de las que se compone un proyecto de implantación de sistemas, pero además hay que señalar también la importancia de al menos dos puntos de control del proyecto. El primero de ellos trata de la viabilidad y continuación del proyecto, y se estructura en dos hitos: Ved también En la asignatura de Ingenie- ría del software en entornos de software libre podéis encontrar más información sobre el ciclo de vida de desarrollo de soft- ware.
  • © FUOC • P08/M2104/00604 18 Implantación, proyectos y empresas de software libre • El primer hito tiene lugar después de la etapa de análisis del estado actual, en la cual se analiza y se discute el estado actual del sistema con respecto a la actuación estratégica. • El segundo hito tiene lugar después de la etapa de diseño, en la cual se analizan y se discuten las soluciones propuestas. Por ejemplo, se puede cuestionar la conveniencia de continuar el proyecto teniendo en cuenta las implicaciones económicas que supone su desarrollo. El segundo punto de control trata de la evaluación del proyecto, y se enmarca temporalmente después de la implantación definitiva del sistema en la orga- nización. En este hito se analizan las repercusiones reales del nuevo sistema una vez se ha finalizado la implantación, evaluando los factores de impacto medibles descritos en la actuación estratégica que ha emprendido el proceso de implantación. El objetivo es evaluar el grado de cumplimiento del nuevo sistema con respecto a la estrategia de la organización. La observación de estos mensurables se realiza en formato de corte longitudinal. Por ejemplo, se puede evaluar el impacto que el nuevo sistema ha tenido en la capacidad productiva de la organización o en la captación de clientes nuevos. 1.1.7. Metodología del proyecto Como en todo proyecto estratégico, la implantación de sistemas se tiene que realizar de manera metodológica, estructurada y ordenada. La importancia del resultado del proyecto para la evolución de la organización promueve la pre- cisión con la cual se tiene que desarrollar. A modo de ejemplo, este concepto se puede contrastar con la metodología que se aplica al ciclo de vida en el desarrollo de un software y la importancia de las fases de análisis conceptual y el diseño de la solución. En esta área, se reconoce la problemática que proviene de no haber detectado una deficiencia en las etapas de análisis y diseño. Globalmente, se considera que solucionar un problema de diseño detectado en la etapa de desarrollo puede tener una relación de coste de uno a diez. De la misma manera, el proyecto de implantación de sistemas requiere la má- xima precisión en las fases de análisis y diseño, vistas las implicaciones estra- tégicas que tendrá la nueva implantación en la evolución de la organización. La ejecución de las etapas descritas en los apartados anteriores tiene un com- portamiento secuencial en el tiempo, inherente a su propio objetivo, pero aun así se puede especializar la metodología de ejecución de cada etapa con el fin de alcanzar los objetivos de manera más eficiente. De esta manera, y a modo de ejemplo, se puede considerar la distribución siguiente: Corte longitudinal Un corte longitudinal hace re- ferencia a que la observación de los mensurables no es única en el tiempo, sino que la ob- servación se repite diversas ve- ces durante un periodo defini- do previamente.
  • © FUOC • P08/M2104/00604 19 Implantación, proyectos y empresas de software libre • La fase de análisis del sistema actual puede seguir un esquema iterativo, con realimentación de los resultados que se obtienen en el estudio. • Las fases de diseño y desarrollo pueden seguir un esquema XP 4 si se tra- ta de desarrollar software, o clásico si se trata de una implantación de in- fraestructura. • La fase de implantación puede seguir un esquema iterativo si la implanta- ción afecta a diversas unidades, considerando la posibilidad de mantener más de una línea de implantación por unidad de tiempo. En cualquier caso, hay que adaptar la metodología de cada etapa a la conve- niencia del proyecto y de la organización, siempre con el objetivo de maximi- zar la eficiencia y minimizar el impacto negativo. 1.2. Tipología de proyectos En este apartado se presenta una clasificación general de los diferentes tipos de proyectos de implantación y se expondrán las diferentes particularidades y las principales implicaciones en el desarrollo del proyecto. Se detallan dos clasificaciones diferentes, primero según el ámbito de actua- ción del proyecto, es decir, la repercusión y alcance de la implantación, y des- pués según el objeto del proyecto, es decir, el contenido de la implantación. No se tiene que entender esta clasificación como una estructura rígida, ya que la diversidad real de los proyectos permite la combinación de diferentes tipo- logías. 1.2.1. Clasificación por ámbito Se pueden definir tres grandes ámbitos de actuación en los proyectos de im- plantación: 1)￿Interno Los proyectos de ámbito interno tienen por objetivo implantar un sis- tema local en la organización que sobre todo se utilizará internamente. Por ejemplo, se pueden considerar de ámbito interno proyectos de implanta- ción de servicios de red local (servicios de directorio, de autentificación o de compartición de datos), de implantación de herramientas de trabajo en grupos locales (correo interno o herramientas de grupo –groupware–) o de implanta- ción de herramientas de gestión interna (sistemas ERP). (4) XP son las siglas de eXtreme Pro- gramming, una metodología ágil para el desarrollo de software.
  • © FUOC • P08/M2104/00604 20 Implantación, proyectos y empresas de software libre El objetivo estratégico de este tipo de proyectos es la mejora funcional interna, en términos de eficiencia y eficacia del trabajo, mediante la renovación tecno- lógica. Su origen se relaciona normalmente con escenarios en que el sistema actual presenta deficiencias funcionales o falta de fiabilidad. A continuación se presentan las principales implicaciones en el desarrollo del proyecto. • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema desde un punto de vista funcional, con la localización y evaluación de los aspectos del sistema que puedan presentar problemas, teniendo siempre como referencia la actuación estratégica que ha previsto la organización. • Diseño￿del￿nuevo￿sistema: El análisis de incidencias hecho en la etapa de diseño tiene que permitir contraponer dos alternativas para afrontar la implantación: por un lado, la evolución del sistema actual y, por otro, su renovación en profundidad. Mientras que la evolución busca la actualización parcial del sistema actual para alargar su vida útil, la renovación en profundidad implica cambios en diversos elementos del sistema (hardware y/o software). • Desarrollo￿del￿nuevo￿sistema: La etapa de desarrollo se mantiene sin cam- bios importantes. En cualquier caso, el alcance local del proyecto puede ayudar a su concreción y resolución estratégica. • Implantación: El ámbito interno del proyecto puede ayudar a la implan- tación progresiva (tiempo y/o servicios) que, conjuntamente con la for- mación del personal, tendrá que ayudar a crear un clima de aceptación mientras se garantiza el funcionamiento diario de la organización. 2)￿Externo Los proyectos de ámbito externo tienen por objetivo implantar en la organización un sistema de utilización principalmente pública, que re- lacione agentes externos con la organización. La ubicación del sistema puede ser local o remota. Por ejemplo, se pueden considerar de ámbito externo proyectos de implanta- ción de intranets o extranets corporativas (acceso personalizado a trabajado- res, clientes o proveedores) o de implantación de administración pública elec- trónica (administración electrónica o voto electrónico).
  • © FUOC • P08/M2104/00604 21 Implantación, proyectos y empresas de software libre El objetivo estratégico de este tipo de proyectos es la mejora funcional de la organización con el exterior, en términos de eficacia y eficiencia de la comu- nicación, mediante la renovación tecnológica. Su origen se relaciona normal- mente con escenarios en los cuales la gestión de la relación digital con terce- ros es compleja o poco eficiente, y también en casos de mejora de la imagen corporativa y del mercado objetivo. A continuación se presentan las principales implicaciones en el desarrollo del proyecto. • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema desde un punto de vista relacional, comunicativo e interactivo. La recolección de datos no se puede restringir únicamente al interior de la organización, de manera que hará falta el contacto con agen- tes externos. Tanto si existe un sistema implantado como si no, el objetivo de la actuación estratégica será evidenciar las carencias y debilidades de la actual implementación relacional. • Diseño￿del￿nuevo￿sistema: El diseño del nuevo sistema tiene que respon- der principalmente a dos tipos de objetivos, por una parte la funcionalidad del usuario en términos de eficiencia y eficacia y, por otra, las considera- ciones relativas a la imagen corporativa que la organización quiere trans- mitir en el mercado objetivo. • Desarrollo￿del￿nuevo￿sistema: La etapa de desarrollo se mantiene sin cam- bios importantes. En cualquier caso, hay que destacar que la gestión de la seguridad es de especial importancia en este tipo de proyectos. • Implantación: La implantación definitiva de estos sistemas se puede ha- cer en dos fases, en un primer momento se puede poner en marcha el sis- tema básico, mientras que la actualización de servicios y contenidos puede ser progresiva en el tiempo, considerando las valoraciones de los usuarios externos sobre los cambios producidos (feedback). 3)￿Productivo Los proyectos de ámbito productivo tienen por objetivo implantar un sistema en un entorno diferente al de la organización que gestiona y/o desarrolla el proyecto (subcontratación). Por ejemplo, se pueden considerar de ámbito productivo proyectos de implan- tación de software de base (sistemas operativos), de implantación de software especializado (herramientas ofimáticas, contables, de facturación, etc.) o de implantación de servicios externalizados (subcontratación de servicios web).
  • © FUOC • P08/M2104/00604 22 Implantación, proyectos y empresas de software libre El objetivo estratégico de este tipo de proyectos es responder a demandas o necesidades de servicios tecnológicos de otras organizaciones o colectivos ex- ternos de diversos ámbitos. Su origen se relaciona normalmente con escena- rios ligados a oportunidades de cambio tecnológico y estratégico del mercado objetivo. A continuación se presentan las principales implicaciones en el desarrollo del proyecto. • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema bajo dos tendencias diferentes. Por una parte, los pro- yectos especializados, en los cuales hay una organización con necesidades estratégicas específicas por cubrir. Por otra parte, los proyectos de implantación directa (sistemas operativos o herramientas ofimáticas), destinados a producir soluciones genéricas ade- cuadas a un conjunto amplio de mercado. En cualquier caso, se evidencia la importancia del estudio del estado de la situación actual. • Diseño￿del￿nuevo￿sistema: La etapa de diseño no presenta cambios signi- ficativos. El proyecto especializado se lleva a cabo siguiendo las conside- raciones de proyecto interno o externo en la organización cliente, mien- tras que el proyecto de implantación directa tiene que satisfacer las ne- cesidades habituales de funcionamiento y/o presentar innovaciones. Hay que destacar la importancia de la tecnología utilizada en el proyecto como imagen corporativa de la organización. • Desarrollo￿del￿nuevo￿sistema: La etapa de desarrollo se mantiene sin cam- bios importantes. Hay que destacar la importancia de que el desarrollo res- ponda con eficiencia y eficacia a los objetivos de la organización cliente, así como la necesidad de hacerlo en los plazos temporales estipulados. • Implantación: Los proyectos especializados siguen una implantación de acuerdo con la tipología de proyecto interno o externo, en la que se destaca la importancia de la formación y la comunicación de los usuarios. Los pro- yectos de implantación directa normalmente se implantan empaquetados en forma de producto autoinstalable (en formato CD-ROM, DVD-ROM o descargables desde Internet). Algunos servicios se pueden considerar com- plementarios (formación, migración, etc.) y realizados bajo demanda por la misma organización o por terceros. 1.2.2. Clasificación por objetivo de los requerimientos Se pueden definir tres grandes grupos de objetivos en proyectos de implanta- ción:
  • © FUOC • P08/M2104/00604 23 Implantación, proyectos y empresas de software libre 1)￿Software Los proyectos de desarrollo de software tienen por objetivo implantar aplicaciones que respondan a determinadas exigencias. También se pue- den considerar de este tipo los proyectos de adaptación, reingeniería o integración de software o herramientas, como la adaptación de sistemas operativos o la integración de paquetes de software especializado. El objetivo estratégico que persiguen este tipo de proyectos es dar una respues- ta tecnológica a una problemática funcional concreta. Su origen se relaciona normalmente con escenarios de implantación de sistemas de automatización de tareas, de soporte tecnológico eficiente a los usuarios o de evolución o re- novación de software obsoleto. A continuación se presentan las principales implicaciones en el desarrollo del proyecto. • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema desde un punto de vista funcional, evaluando la efi- ciencia y la eficacia del conjunto con respecto a la actuación estratégica que inicia el proyecto. En los proyectos de creación de software nuevo o genérico, la evaluación se centra en el estudio y análisis del estado actual del mercado objetivo y de las tendencias que lo guían. • Diseño￿del￿nuevo￿sistema: La etapa de diseño se mantiene sin cambios importantes con respecto al ciclo de vida de producción de software que hemos estudiado en otras asignaturas. Hay que destacar la importancia metodológica de las fases de análisis de necesidades y diseño del sistema, con el objetivo de minimizar los errores que se detecten en etapas poste- riores. • Desarrollo￿del￿nuevo￿sistema: La etapa de desarrollo también se mantiene sin cambios importantes con respecto al ciclo de vida habitual de este tipo de proyectos. Hay que remarcar la importancia de los mecanismos que aseguren la calidad del código producido, así como la evolución del código en versiones y revisiones. • Implantación: De la etapa de implantación del sistema se pueden diferen- ciar dos tendencias. Por una parte, el desarrollo de software que hay que instalar en una organización, que seguirá el proceso habitual teniendo en cuenta la eventual necesidad de emprender una migración en caso de que haya un sistema implantado actualmente. Por otra parte, el software de uso común o genérico normalmente se implanta empaquetado en forma de producto autoinstalable, en formato CD-ROM, DVD-ROM o descarga- Ved también Con respecto al ciclo de vida de producción de software, consultad la asignatura Inge- niería del software en entornos de software libre.
  • © FUOC • P08/M2104/00604 24 Implantación, proyectos y empresas de software libre ble desde Internet. Algunos servicios se pueden considerar complementa- rios (formación, migración, etc.) y realizados bajo demanda por la misma organización o por terceros. 2)￿Infraestructura Los proyectos de implantación de infraestructura tienen por objetivo implantar sistemas de base estructural o arquitectural en un entorno determinado. Normalmente, estos proyectos se relacionan con la im- plantación de equipamiento funcional de servicio básico para la orga- nización. El objetivo estratégico que persiguen este tipo de proyectos es ofrecer una base tecnológica funcional y adecuada a los requisitos de la organización. Su origen se relaciona normalmente con escenarios de nueva creación o de renovación tecnológica por obsolescencia del sistema. Hay que tener en cuenta que la infraestructura de la organización es su arquitectura básica funcional sobre la cual se dispondrán el resto de elementos tecnológicos. A continuación se presentan las principales implicaciones en el desarrollo del proyecto: • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema desde un punto de vista funcional, considerando as- pectos como la eficiencia y la eficacia pero también la fiabilidad y la ade- cuación a los nuevos estándares que impone la evolución tecnológica. En los casos en que no haya un sistema ya implantado, se tendrán pre- sentes principalmente las necesidades de la organización (en cantidad y calidad), así como las tendencias y estándares actuales. • Diseño￿del￿nuevo￿sistema: La etapa de diseño se centra principalmente en la investigación y estudio de las diferentes soluciones que ofrece el merca- do, aunque no se puede descartar la creación o evolución de una solución si las necesidades de la organización lo requieren. De la comparativa tiene que surgir el producto más adecuado a la actuación estratégica, conside- rando criterios de evaluación como la extensión, la eficiencia y eficacia de la solución, las necesidades del equipamiento y el soporte, disponibilidad y mantenimiento del producto. • Desarrollo￿del￿nuevo￿sistema: La etapa de desarrollo del sistema compor- ta la preparación de los procedimientos para implantar la infraestructura, considerando que algunas veces es necesaria la adecuación del producto o el ajuste de ficheros de configuración. Equipamiento funcional de servicio básico Es el caso, por ejemplo, de la instalación y configuración de servidores o clientes, como sistemas operativos, software de ofimática, servicios de red básicos (DNS, DHCP, etc.) o avanzados (correo, groupware, etc.).
  • © FUOC • P08/M2104/00604 25 Implantación, proyectos y empresas de software libre • Implantación: Si el nuevo sistema sustituye uno anterior, hará falta un proceso de migración de un sistema al otro. Sin embargo, en la implanta- ción se pueden diferenciar dos fases: en primer lugar, la instalación y con- figuración de las novedades en el nuevo sistema, y después la puesta en funcionamiento y restauración del estado. No hay que olvidar que, en este tipo de proyectos, la comunicación y la formación de los usuarios es fundamental para la aceptación de las nove- dades, así como la evaluación del funcionamiento una vez se ha puesto en marcha. 3)￿Migración￿de￿sistemas Los proyectos de migración de sistemas tienen por objetivo trasladar o transferir el estado de la arquitectura tecnológica actual a otra diferente. Estos proyectos surgen de la actualización de un elemento principal del sistema o más. El objetivo estratégico que persiguen este tipo de proyectos es minimizar el impacto de los cambios tecnológicos que puedan afectar al funcionamiento de la organización. Su origen se relaciona normalmente con escenarios de im- plantación de nuevos sistemas de software o de infraestructura, aunque tam- bién pueden existir de manera independiente por sustitución de la plataforma tecnológica física por motivos de rendimiento, fiabilidad u obsolescencia. A continuación se presentan las principales implicaciones en el desarrollo del proyecto: • Evaluación￿del￿sistema￿actual: Esta etapa plantea principalmente la eva- luación del sistema desde un punto de vista de salvaguardia de la configu- ración y de los datos almacenados. Será importante proceder de manera metodológica en la investigación y evaluación de los diferentes elementos que será necesario migrar al nuevo sistema. • Diseño￿de￿la￿migración: La etapa de diseño normalmente se centra en estudiar y analizar los métodos y procedimientos que habrá que imple- mentar para transferir el estado entre los sistemas. Se pueden considerar aspectos como la preparación de las copias de seguridad o el diseño de los procedimientos para exportar o convertir los datos del sistema actual. • Desarrollo￿de￿la￿migración: El desarrollo de la migración comporta la realización de todas aquellas tareas de salvaguardia de datos y configura- ción, de exportación y conversión sobre el sistema actual. Hay que valorar la importancia que tiene la ubicación temporal de su realización, con el fin de garantizar el traspaso íntegro de datos sin impedir el funcionamien-
  • © FUOC • P08/M2104/00604 26 Implantación, proyectos y empresas de software libre to de la organización. También hay que tener en cuenta las garantías de seguridad que ofrece el soporte de la salvaguardia. • Implantación: La implantación hace referencia a la puesta en marcha del nuevo sistema y la restauración del estado del sistema anterior de la orga- nización. Es importante que este proceso esté planificado temporalmente de manera conjunta con la etapa de desarrollo de la migración, con el fin de minimizar el impacto del cambio en el funcionamiento de la organi- zación, aunque se puede prever la restauración progresiva de algunos ele- mentos menos prioritarios. En este tipo de proyectos, la comunicación y la colaboración con los usuarios es especialmente importante para cumplir los objetivos de la migración con garantías de éxito. 1.3. Los sistemas basados en software libre En este apartado se presentan las particularidades de la implantación de siste- mas basados en software libre. Se analizan los principales factores que influyen en el proyecto y los mitos, ventajas e inconvenientes de utilizarlo. Cuando se habla de software libre generalmente se suele hacer referen- cia a sus ventajas, bastante conocidas. Así, el software libre es de distri- bución libre, seguro, de calidad, se basa en estándares abiertos, puede utilizarse en cualquier lugar, se basa en la cultura de la colaboración y la favorece, mejora la capacidad tecnológica, permite reducir costes fijos y variables en los sistemas informáticos, reduce la dependencia de pro- veedores y fomenta el desarrollo de las empresas locales. Sin embargo, las empresas dedicadas a la implantación de sistemas basados en software libre se encuentran con una serie de problemas que frenan el desa- rrollo del sector (Sáez y otros). En general, a fin de que una tecnología se desarrolle, es necesario que esta tecnología sea viable comercialmente, es decir, que haya una oferta y una de- manda, y económicamente, de manera que las empresas del sector obtengan beneficios de la implantación de la tecnología. Con respecto a la demanda, es decir, las empresas que podrían adoptar el software libre, los principales obstáculos están relacionados con la piratería, el miedo al cambio y la desconfianza. Las empresas confunden el software libre con el gratuito, y algunas compañías descartan su implantación, o bien porque no hay software libre con niveles de calidad parecidos o bien porque no confían en que detrás haya empresas que garanticen el mantenimiento y soporte de este software.
  • © FUOC • P08/M2104/00604 27 Implantación, proyectos y empresas de software libre Con respecto a la oferta, es decir, las empresas proveedoras de aplicaciones y servicios de software libre, los obstáculos son básicamente el miedo al cambio y la falta de espíritu de cooperación. Generalmente, las empresas de informática están acostumbradas a desarrollar software a medida, sin suministrar las fuentes a sus clientes, y manteniendo un modelo de pago por licencias de uso. Sin embargo, gracias a la aparición del software libre, algunas empresas están viendo que puede ser un modelo de negocio sostenible aquél que se basa en el cobro por servicios y no por li- cencias, lo que los ha llevado a liberar parte del código que hasta hoy día ha- brá sido privado. De esta manera, una posibilidad que inicialmente podría ser utilizada por muchas empresas sería la de ofrecer dos soluciones a sus clien- tes, la de propiedad (con coste de licencia) y la libre (normalmente, sin coste de licencia). Éste es sólo uno de los muchos modelos de negocio asociados al software libre. Por otra parte, las empresas informáticas también están acostumbradas a de- sarrollar software de manera individual, y en este sentido una opción mejor sería la de apostar por el modelo cooperativo con el fin de desarrollarlo. Eso implica reaprovechar el trabajo de los otros, colaborar y trasladar los ahorros en licencias al cliente final. Los proyectos basados en software libre pueden plantearse como proyectos normales desde el punto de vista de la ingeniería del software y de la gestión de proyectos. Sin embargo, un análisis más detallado revela algunas diferen- cias y particularidades, cuyo tratamiento se aprende muchas veces con la ex- periencia, y la omisión de las cuales puede afectar e incluso llevar al fracaso a algunos proyectos. En este contexto, la puesta en práctica de una metodología completa para la implantación de sistemas basados en software libre es esencial, sobre todo por dos motivos: • Transmite más confianza￿al￿cliente con respecto a la calidad de los pro- ductos y los procesos, tanto si se trata del desarrollo de un nuevo programa o aplicación, de la migración de un sistema ya en funcionamiento o de la puesta en marcha de uno nuevo. • Permite que las empresas proveedoras sistematicen el procedimiento de implantación￿de￿sistemas￿basados￿en￿software￿libre y se familiaricen con sus particularidades, con la consiguiente mejora en la eficiencia y mi- tigación del miedo al cambio.
  • © FUOC • P08/M2104/00604 28 Implantación, proyectos y empresas de software libre 1.4. Gestión de proyectos en software libre La gestión de proyectos se divide en nueve áreas de conocimiento clá- sicas: • Alcance • Tiempo • Integración • Coste • Calidad • Recursos humanos • Comunicación • Riesgos • Suministros En este apartado se revisará cada una de ellas y se estudiarán sus particulari- dades cuando se aplican a los proyectos de implantación de sistemas de soft- ware libre. 1.4.1. Gestión del alcance La gestión del alcance consiste en la definición de los objetivos del proyecto, de manera que sea posible verificar el cumplimiento y, eventualmente, cam- biarlos. Dicho de otra manera, la gestión del alcance se ocupa de que el pro- yecto lleve a cabo todo el trabajo necesario, y sólo el trabajo necesario, para cumplir los objetivos marcados al inicio. Definición￿del￿alcance￿del￿proyecto Para definir el alcance de un proyecto, el jefe que lo gestiona tiene que esta- blecer la estructura de desagregación del proyecto (EDP), con la cual el pro- yecto queda dividido en paquetes de trabajo, representados habitualmente en forma de árbol lógico. Un paquete de trabajo es la unidad más pequeña en que se puede dividir un proyecto de manera que sea gestionable de indepen- dientemente. Así, se identificará todo lo que se tiene que hacer en el proyecto a través de su correspondiente EDP, describiendo brevemente los paquetes de trabajo que lo componen junto con los entregables que cada uno de ellos necesita o facilita. Cambios￿en￿el￿alcance￿del￿proyecto A veces puede convenir modificar el alcance y los objetivos del proyecto mien- tras se está ejecutando. Eso se puede deber a los motivos siguientes:
  • © FUOC • P08/M2104/00604 29 Implantación, proyectos y empresas de software libre • Deficiencias en el plan de proyecto original, especialmente por una defi- nición incorrecta del alcance. • Cambios en las necesidades y requisitos planteados por el cliente en el plan de proyecto inicial. • Cambios en el contexto del proyecto y, por lo tanto, en las hipótesis con- sideradas cuando se realizó el plan de proyecto inicial. Estas contingencias pueden afectar de manera importante a la ejecución del proyecto, modificando e incluso impidiendo la consecución de sus objetivos. Por ello, el control de los cambios es esencial, y se tiene que tener en cuenta en la gestión de riesgos. Gestión￿del￿alcance￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión del alcance en proyectos basados en software libre presenta las mis- mas características que cualquier otro proyecto de software. Será fundamental una captura y análisis detallado de los requisitos del cliente, y también de la situación actual del sistema cuando se trate de proyectos de migración. En general, la definición del alcance del proyecto basado en software libre de- penderá de cuál sea la motivación del proyecto: reducción de costes, mejora del sistema, independencia ante los distribuidores o regularización de la situa- ción de las licencias de software. Finalmente, es importante destacar que, a veces, el cliente puede no ser cons- ciente de las consecuencias de los cambios en el proyecto, una vez ya se ha puesto en marcha. 1.4.2. Gestión del tiempo La gestión del tiempo tiene como objetivo asegurar que el proyecto se lleve a cabo en los plazos previstos. Para eso habrá que definir la secuencia de activi- dades que se tienen que realizar, así como su duración y coordinación. Una buena planificación del tiempo es una herramienta fundamental en la di- rección de un proyecto, ya que representa el modelo a partir del cual se llevará a cabo y permite asegurar que se están alcanzando sus objetivos, facilita las bases para realizar la integración del tiempo, los costes y los recursos y propor- ciona un marco común para las diferentes personas y socios que participan. Red￿del￿proyecto A partir del EDP que hemos visto en el apartado anterior, se identificarán las actividades necesarias para realizar el proyecto, teniendo presente que una actividad es la parte de trabajo más pequeña en que se puede dividir el proyecto con el fin de llevar a término la planificación.
  • © FUOC • P08/M2104/00604 30 Implantación, proyectos y empresas de software libre A continuación, se identificará la secuencia en la cual se tienen que realizar las actividades: aquéllas que son independientes y que pueden realizarse en paralelo y aquéllas que son dependientes, es decir, que para su realización necesitan el resultado de una actividad precedente. Diagrama￿de￿Gantt El diagrama de Gantt es el instrumento que permite resolver el problema de la programación de actividades (es decir, su distribución conforme a un calen- dario) y representar gráficamente la duración de cada actividad, sus fechas de inicio y de final y, en consecuencia, el tiempo total requerido para la ejecución del proyecto. Además, los diagramas de Gantt permiten controlar el progreso del proyecto, ya que indican el porcentaje realizado por cada actividad y de- tectan avances o retrasos en relación con la planificación inicial. Un diagrama de Gantt consiste en un sistema de coordenadas en el cual se representa: • Eje horizontal: escala de tiempo, en las unidades más adecuadas al proyec- to, habitualmente días, semanas o meses. • Eje vertical: paquetes de trabajo, actividades y subactividades identificadas en el EDP, cuya duración se representa sobre el eje horizontal. La principal ventaja de los diagramas de Gantt es que no hace falta una gran cantidad de información para utilizarlo; de hecho, basta con que exista un plan no demasiado detallado del proyecto. Por ello, es un instrumento de uso sencillo y es especialmente eficaz cuando se está planificando inicialmente el proyecto. Sin embargo, una vez ha empezado el proyecto, y en especial si éste presenta una complejidad elevada, el diagrama de Gantt puede resultar confuso. Método￿del￿camino￿crítico￿y￿PERT Con el fin de superar las limitaciones de los diagramas de Gantt, se han desa- rrollado otros instrumentos, entre los cuales destacan los métodos de camino crítico (CPM) y PERT. El camino crítico en un proyecto es la sucesión de actividades que dan lugar al máximo tiempo acumulado. Determina el tiempo más corto que tarda a rea- lizarse el proyecto si disponemos de todos los recursos necesarios. Para eso se tienen que identificar bien todas las actividades y debe conocerse su duración.
  • © FUOC • P08/M2104/00604 31 Implantación, proyectos y empresas de software libre Con el fin de representar las actividades y las dependencias temporales se uti- lizan grafos dirigidos, en los cuales cada flecha representa una actividad iden- tificada por su nombre y duración, de manera que el avance del proyecto mo- difica el estado. Cada estado se representa por un nodo entre dos o más flechas. De esta manera hay tareas que se pueden realizar en paralelo y otras que no. La principal diferencia entre el CPM y el PERT se encuentra en la estimación del tiempo. El CPM considera que los tiempos de las actividades (m) se cono- cen de manera exacta y varían según los recursos asignados. En cambio, el PERT supone que el tiempo de las actividades (Te) es determinado por una distribución de probabilidad dada por la duración estimada más probable (m), la duración estimada más optimista (a) y la duración estimada más pesimista (b). De esta manera los tiempos pesimistas y optimistas dan una medida de la incertidumbre de cada actividad. Para calcular el camino crítico se siguen los pasos siguientes: 1. Calcular Te o m para cada actividad, según el método utilizado. 2. Calcular las fechas mínimas de comienzo (early) de cada actividad (MIC) y las fechas máximas de comienzo (last) de cada actividad (MAC). Cálculo del MIC El MIC de cada acontecimiento se calcula como el máximo de la duración de las activi- dades anteriores más el MIC del acontecimiento anterior. El MAC es la fecha máxima en la cual pueden cumplirse los acontecimientos sin representar un retraso en la finali- zación del proyecto. 3. Calcular los márgenes de cada actividad El margen de una actividad El margen de una actividad es el suplemento de tiempo que tenemos para determinar esta actividad: • Margen de un acontecimiento: Hs = MAC del acontecimiento – MIC del aconteci- miento. • Margen de una actividad: Ht = MAC del acontecimiento posterior – MIC del aconte- cimiento anterior – duración de la actividad. 4. Identificar el camino crítico del proyecto Una actividad es crítica cuando no se pueden cambiar sus instantes de comien- zo y finalización sin modificar la duración total del proyecto. Las actividades críticas no tienen margen y la concatenación de actividades críticas es el ca- Ved también Para profundizar en cada uno de estos métodos, se reco- mienda consultar la bibliogra- fía indicada al final del módu- lo.
  • © FUOC • P08/M2104/00604 32 Implantación, proyectos y empresas de software libre mino crítico. Dicho de otra manera, en una actividad crítica la fecha mínima de comienzo coincide con la más tardía de comienzo, y la fecha más temprana de finalización coincide con la fecha máxima de comienzo de la actividad. Gestión￿del￿tiempo￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión del tiempo en proyectos basados en software libre presenta en prin- cipio las mismas características que cualquier otro proyecto de software. En los proyectos de desarrollo de programas y aplicaciones en los cuales la participación de la comunidad de desarrolladores de software libre tiene un papel importante, es esencial calcular correctamente los plazos dedicados al desarrollo del software. Por ello hace falta conocer los antecedentes de la co- munidad y discutir el plan de implementación futuro. También es recomen- dable implicarse en la comunidad y familiarizarse con su forma de trabajar antes de iniciar el proyecto. En los proyectos de migración es esencial dimensionar correctamente el tiem- po necesario para llevar a cabo la formación de los usuarios, e incluso prever cierta flexibilidad para realizar la migración de los usuarios. En consecuencia, ciertos proyectos de software libre pueden tener asociada una incertidumbre bastante alta, por lo que resulta recomendable la utiliza- ción de la técnica PERT con la finalidad de caracterizar adecuadamente los es- cenarios más optimistas y pesimistas en el plan de proyecto. Hay numerosas aplicaciones libres que permiten la creación y mantenimiento de diagramas de Gantt y PERT. 1.4.3. Gestión de la integración La gestión de la integración tiene como objetivo asegurar que las diferentes partes del proyecto están coordinadas correctamente. Esto incluye el desarrollo del plan del proyecto, el plan de ejecución y el control de los cambios que se puedan llegar a producir. Gestión￿de￿la￿integración￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión de la integración en proyectos basados en software libre presenta en general las mismas características que cualquier otro proyecto de software, pero conviene tener en cuenta ciertas particularidades. Aplicaciones libres Son aplicaciones libres, por ejemplo, GanttProject (http:// ganttproject.sourceforge.net/ ) o OpenWorkbench (http:// www.openworkbench.org/).
  • © FUOC • P08/M2104/00604 33 Implantación, proyectos y empresas de software libre En general, la integración en proyectos basados en software libre presenta cier- tas ventajas con respecto a los proyectos basados en software propietario, fun- damentalmente a causa del código abierto y del uso de estándares abiertos que facilitarán la interoperabilidad de aplicaciones, sobre todo con aquéllas desa- rrolladas fuera del proyecto. En los proyectos de desarrollo realizados en colaboración con una comunidad externa al proyecto, es importante hacer público y discutir el plan de imple- mentación tanto del proyecto como de la comunidad, con el fin de identificar posibles incompatibilidades que puedan dificultar la integración. 1.4.4. Gestión del coste La gestión del coste tiene como objetivo que el proyecto se complete con el presupuesto inicialmente aprobado. Ello comporta la planificación de los re- cursos necesarios y la estimación y el control de los costes. Gestión￿del￿coste￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión del coste en proyectos basados en software libre difiere considera- blemente de un proyecto basado en software propietario. La principal diferencia reside en el coste de las licencias, que normalmente será nulo para el software libre. En cambio, se tendrán en cuenta los costes de servicios prestados por terceros, siguiendo cualquiera de los modelos de negocio basados en software libre. 1.4.5. Gestión de la calidad La gestión de la calidad tiene como objetivo que el proyecto satisfaga las ne- cesidades para las cuales fue diseñado inicialmente. Para eso se tiene que pla- near, asegurar y controlar continuamente la calidad del proyecto en relación con estas necesidades. Gestión￿de￿la￿calidad￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión del tiempo en proyectos basados en software libre presenta en prin- cipio las mismas características que cualquier otro proyecto de software. Por una parte, se debe tener en cuenta la calidad desde el punto de vista del usuario, con la adopción de los estándares necesarios en cada caso. Por otra parte, en los proyectos en los cuales se trabaje con la comunidad de software libre, sea contribuyendo a un proyecto ya existente o sea creando un de nuevo, hay que tener en cuenta la calidad del código producido desde el punto de vista de quien lo desarrolla.
  • © FUOC • P08/M2104/00604 34 Implantación, proyectos y empresas de software libre Hay que respetar las recomendaciones de estilo de programación, convencio- nes de nombres, documentación, registros y formatos de error, idiomas, etc. En caso de que se trate de un nuevo proyecto, convendrá hacer públicas estas recomendaciones. 1.4.6. Gestión de recursos humanos La gestión de recursos humanos tiene como objetivo la utilización más efi- ciente posible de las personas que participan en el proyecto, y entre sus acti- vidades hay el plan organizacional, la contratación de nuevos empleados y el desarrollo de los equipos. Gestión￿de￿los￿recursos￿humanos￿en￿los￿proyectos￿basados￿en￿software libre La gestión del tiempo en proyectos basados en software libre presenta en prin- cipio las mismas características que cualquier otro proyecto de software, pero conviene tener en cuenta ciertas particularidades. Principalmente, se tendrá que evaluar la posible participación en la comuni- dad de software libre y también la contribución efectiva que pueda tener esta comunidad en el proyecto. En general, irá bien definir un responsable de las relaciones con las comunidades de software libre asociadas al proyecto. 1.4.7. Gestión de la comunicación La gestión de la comunicación tiene como objetivo asegurar la correcta gene- ración, recolección, diseminación, almacenamiento y eliminación de la infor- mación del proyecto, en unos plazos determinados. Gestión￿de￿la￿comunicación￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión de la comunicación en proyectos basados en software libre presenta en principio las mismas características que cualquier otro proyecto de softwa- re. Es muy importante asegurar la comunicación y diseminación de la infor- mación dentro del proyecto, especialmente cuando se colabora con la comu- nidad de software libre. En caso de que no se trabaje con la comunidad de software libre, pero se previera la posibilidad de liberar el código, o si el clien- te deseara tener acceso al mismo, sería igualmente importante que el código fuente se pudiera leer y estuviera bien documentado. Estilos de programación estándar Hay que tener en cuenta que existen estilos de programa- ción ya definidos y aceptados por la comunidad que convie- ne seguir, como las Java Code Conventions o Linux C kernel style.
  • © FUOC • P08/M2104/00604 35 Implantación, proyectos y empresas de software libre La configuración y utilización correcta de los forjas de software o entornos de colaboración de desarrollo (CDE) tiene, por lo tanto, un papel fundamental. La mayoría de forjas incorpora herramientas para la gestión general del proyecto, seguimiento de errores, foros, listas de correo, etc. De la misma manera, las forjas públicas disponen también de estas herramientas, y ofrecen la ventaja de ofrecer más visibilidad a la comunidad de software libre. Entre las herramientas de comunicación podemos destacar listas de correo, canales IRC, blogs, foros y wikis. Es importante que las decisiones relevantes tomadas a través de estas herramientas se documenten adecuadamente y se pongan a disposición de todos los que las desarrollen. Con respecto a la documentación, es recomendable definir las reglas a seguir con el fin de elaborarla, así como las herramientas que se utilizarán para su generación automática. 1.4.8. Gestión de riesgos La gestión de riesgos tiene como objetivos identificar, analizar y dar respuesta a los posibles acontecimientos que amenacen el plan del proyecto, en forma de retrasos en el mismo y aumento de los costes. Estos riesgos tienen que estar correctamente identificados y cuantificados, así como los mecanismos de respuesta pertinentes. Un riesgo presenta siempre las características de incertidumbre, ya que el acontecimiento que caracteriza al riesgo puede ocurrir o no, y de pérdida, ya que si el acontecimiento finalmente ocurre se producirán consecuencias negativas o pérdidas para el proyecto. Por ello, con el fin de caracterizar los riesgos es esencial evaluar correctamente su probabilidad y las pérdidas asociadas. Existen múltiples clasificaciones de riesgos. Como primera aproximación, se pueden considerar los siguientes tres tipos de riesgos: • Riesgos de gestión, relacionados con problemas en la planificación tem- poral, el presupuesto y la organización de personal y recursos. • Riesgos técnicos, que amenazan la calidad y la planificación temporal del proyecto y dificultan el desarrollo y la implantación del mismo. Los ries- gos técnicos más frecuentes están asociados a problemas potenciales de diseño, implementación, verificación o mantenimiento. Su origen suele hallarse en la existencia de ambigüedades en requisitos y especificaciones y en el uso de tecnologías anticuadas o demasiado nuevas. • Riesgos de negocio, que amenazan la viabilidad del proyecto. Por ejemplo, desarrollar un proyecto para el cual no existe bastante mercado o que no encaja con la línea comercial de la empresa. Gestión￿de￿riesgos￿en￿los￿proyectos￿basados￿en￿software￿libre Forjas de software Podéis consultar ejemplos de forjados de software o entor- nos de colaboración de desa- rrollo en las siguientes webs: Gforge, LibreSource o Trac. Web complementaria Podéis consultar un ejem- plo de forja pública en la siguiente web: http:// www.sourceforge.net.
  • © FUOC • P08/M2104/00604 36 Implantación, proyectos y empresas de software libre La gestión del riesgo en proyectos basados en software libre presenta en prin- cipio las mismas características que cualquier otro proyecto de software. Un ejemplo clásico de riesgo en los proyectos basados en software libre son los que se relacionan con el miedo y la incertidumbre –tanto de la organiza- ción como de los usuarios– del cambio tecnológico en una nueva plataforma, eventualmente desconocida. Convendrá asegurarse al inicio del proyecto de establecer métodos de comu- nicación y formación para reducir los eventuales impactos negativos asocia- dos al rechazo del cambio tecnológico. Una buena práctica es establecer un periodo de presentación, difusión y formación de los usuarios, sostenido y progresivo a lo largo de la implantación, que ofrezca tanto la visión global del software libre como la de aplicaciones y herramientas concretas. Otro ejemplo clásico de riesgo en los proyectos basados en software libre son las posibles incompatibilidades legales entre licencias libres, de código desa- rrollado y reutilizado. Convendrá asegurarse al inicio del proyecto que las licencias que se aplican a las diferentes partes del código son coherentes entre ellas, y que los planes de desarrollo no producirán ninguna incompatibilidad. Esta misma compro- bación se tiene que realizar antes de cada release. Una buena práctica es dis- poner siempre de un mapa de licencias, que recoja la licencia bajo la cual se distribuye cada uno de los paquetes de software y las interacciones entre cada uno de ellos. 1.4.9. Gestión de suministros La gestión de suministros tiene como objetivos garantizar que los materiales y recursos necesarios para la ejecución del proyecto estén disponibles a tiempo y en el lugar necesario. Gestión￿de￿suministros￿en￿los￿proyectos￿basados￿en￿software￿libre La gestión de suministros en proyectos basados en software libre presenta en principio las mismas características que cualquier otro proyecto de software. La migración e implantación de un sistema basado en software libre suele ser un buen momento para renovar equipos o para modificar la estructura de la red de la organización, para lo cual el plan de proyecto debe tener en cuenta los pedidos de nuevos equipos y material con el fin de tener en cuenta posibles retrasos y evitarlos.
  • © FUOC • P08/M2104/00604 37 Implantación, proyectos y empresas de software libre 2. El proyecto de software libre Un proyecto es un proceso de gestión de recursos organizado y estructurado para alcanzar un determinado objetivo, normalmente estratégico. Mientras que en la primera parte se han presentado los aspectos más importantes de la gestión funcional de los recursos, este módulo centra su atención en las etapas que tiene que seguir el proyecto para alcanzar sus objetivos. En general, se pueden identificar siete etapas importantes en los proyectos de implantación de sistemas de software libre: • Estudio de la situación actual • Estudio de los requisitos de la implantación • Análisis de las soluciones en software libre • Formalización de la propuesta • Desarrollo • Implantación y migración • Formación, documentación y soporte al usuario Como se puede observar, estas etapas son fruto del desarrollo de las fases pre- sentadas en el primer apartado de esta unidad y de la aplicación particular alre- dedor del software libre. Sin embargo, el desarrollo que se presenta es bastante genérico y permite que se pueda aplicar a otros procesos de implantación. En este apartado se presenta el ciclo de vida del proyecto y ofrece una visión global del proceso, de las etapas y de su relación con la gestión del proyecto y con los recursos que se dedican. Los siete apartados siguientes se dedicarán a desarrollar detalladamente las etapas del proyecto, enlazando y ampliando los conceptos ya presentados en el primera parte de este módulo. 2.1. Ciclo de vida En este primer apartado se presentan las principales características metodoló- gicas y funcionales del ciclo de vida del proyecto, con el objetivo de propor- cionar una visión global del proceso. El ciclo de vida del proyecto enlaza los aspectos metódicos, inherentes al de- sarrollo de las etapas de la implantación, con la gestión funcional del proyec- to. En este sentido, el ciclo de vida guía la ejecución de las diferentes etapas a través del tiempo y de los recursos disponibles.
  • © FUOC • P08/M2104/00604 38 Implantación, proyectos y empresas de software libre Globalmente, el ciclo de vida de un proyecto tiene dos objetivos principales: • Por una parte, establece las relaciones y dependencias entre las etapas, ya sean temporales o funcionales. • Por otra parte, permite reducir el riesgo del proyecto gracias a la división de su complejidad. Con el ciclo de vida del proyecto se puede controlar la evolución de las eta- pas, el calendario temporal de ejecución y el coste económico del proyecto. Hay que destacar que la gestión del ciclo es dinámica, por lo que se pueden tomar decisiones de modificación y adecuación a lo largo del tiempo con el objetivo de reajustar la estimación de los parámetros iniciales en función de los acontecimientos reales. A grandes rasgos, hay cuatro aspectos importantes del ciclo de vida: el proyec- to, las etapas, la ejecución y los resultados. 2.1.1. El proyecto Ved también Podéis conocer más detalles de la gestión del riesgo consultan- do el apartado sobre gestión de riesgos de la unidad ante- rior. El proyecto de implantación de sistemas, como cualquier otro proyecto, se propone la consecución de un conjunto de objetivos en un tiempo determinado y con un conjunto de recursos determinado. Normalmente, minimizar el tiempo o los recursos que se dedican al proyec- to conducirá a minimizar los objetivos que se puedan alcanzar o a disminuir su calidad, y viceversa. En cambio, minimizar el tiempo del proyecto mante- niendo los objetivos del mismo requiere un aumento de los recursos que se dedican. La gestión del proyecto busca el equilibrio más factible entre estos tres elementos. En cualquier caso, los cambios que se producen en la relación de estos tres elementos tienen repercusiones económicas directas que habrá que asumir en caso de actualización. En este sentido, la propia gestión del proyecto tiene aso- ciado un coste económico desde el primer momento que se inicia el proyecto (cuando se decide asignar tiempo de uno o más trabajadores para iniciar la gestión). Normalmente, los principales factores que influyen en el tiempo y en los re- cursos necesarios para llevar a cabo el proyecto tienen relación con el tamaño y la complejidad del sistema a implantar. En este sentido, las características del software libre favorecen la reducción de los costes temporales y económicos asociados al proyecto: Ved también Podéis conocer más detalles de la gestión de los proyectos consultando el apartado de gestión de proyectos en soft- ware libre de la unidad ante- rior.
  • © FUOC • P08/M2104/00604 39 Implantación, proyectos y empresas de software libre • Variedad￿de￿aplicaciones. La madurez del mercado de software libre ofre- ce una amplia variedad de productos de implantación directa fiables, con- sistentes y seguros. • Coste￿de￿las￿licencias. Normalmente, el software libre se puede conseguir sin costes de licencia y se puede descargar directamente desde la web oficial o desde otros depósitos públicos. • Modificación￿del￿código￿fuente. La apertura del código fuente permite la ampliación, modificación y ajuste de los productos allí donde con modelos de licencias de propiedad haría falta un desarrollo nuevo, si se quisiera hacer evolucionar el producto. Es importante destacar que el software libre también contribuye a disminuir el riesgo global del proyecto, gracias a las características de libertad de visuali- zación, utilización y modificación del código fuente, que permiten evaluar y valorar en profundidad todos los aspectos de la aplicación. Por otra parte, el proyecto se puede gestionar y ejecutar de manera interna o externa a la organización. A grandes rasgos, se pueden distinguir dos casos principales: • Insourcing: corresponde a los casos en que la organización asume el desa- rrollo del proyecto emprendido a partir de una actuación estratégica. Es decir, el departamento de informática de la organización gestiona y ejecu- ta el proyecto. • Outsourcing￿o￿subcontratación: corresponde a los casos en que la organi- zación delega la gestión y el desarrollo del proyecto a una organización externa dedicada a la gestión y ejecución de proyectos 5 . Es decir, la orga- nización reduce su exposición directa al desarrollo del proyecto. En este sentido, el formato de desarrollo del proyecto se decidirá consideran- do la capacidad y experiencia de la organización que tiene que asumir el de- sarrollo del proyecto, los costes asociados, el calendario temporal de puesta en marcha y la especialización de las organizaciones externas en el proyecto. Finalmente, el proyecto se evalúa en términos de beneficios tangibles e intan- gibles, y aquí se pueden dar casos en que sea plausible un sobrecoste temporal o económico para alcanzar beneficios intangibles, normalmente estratégicos, que la organización requiere. Por ejemplo, mejorar la imagen corporativa con el uso y la difusión del software libre y la filosofía libre. (5) Por ejemplo, las consultorías tec- nológicas ejecutan proyectos por cuenta ajena.
  • © FUOC • P08/M2104/00604 40 Implantación, proyectos y empresas de software libre 2.1.2. Las etapas El ciclo de vida del proyecto se implementa en forma de etapas sucesivas y, eventualmente, simultáneas en el tiempo. Cada etapa cumple un objetivo cla- ro y definido en un escenario relacionado con el proyecto, de tal manera que el conjunto de etapas cumplan los objetivos del proyecto. A grandes rasgos, se puede entender una etapa como un proceso que recibe unas entradas y produce unas determinadas salidas. Es decir, re- quiere de un escenario previo con información sobre el entorno para producir unos determinados resultados. En este sentido, se establece una relación entre las diferentes etapas del pro- yecto, ya que cada etapa cumple una parte de sus objetivos globales. Normal- mente, esta relación puede tomar dos formas: • Dependencia: entre dos etapas determina que una etapa requiere el resul- tado de la ejecución de la otra para poder cumplir su tarea. Eso implica que las etapas se tendrán que ejecutar inevitablemente de manera secuen- cial en el tiempo, en primer lugar la etapa generadora de los resultados y en segundo lugar la etapa consumidora de los resultados. Por ejemplo, la etapa de desarrollo requiere del estudio y análisis de los requisitos de la implantación de sistemas para poder cumplir su tarea. • Independencia: entre dos etapas determina que dos etapas no tengan una relación directa ni ningún prerrequisito concreto. Eso implica que las eta- pas se podrán ejecutar de manera simultánea en el tiempo, aunque es po- sible que sean necesarios más recursos. Por ejemplo, la etapa de implanta- ción del sistema podría ejecutarse de manera simultánea con la etapa de formación de los usuarios. Por otra parte, las etapas también permiten la ejecución del proyecto de ma- nera distribuida, es decir, que una o más etapas sean encargadas a diferentes equipos, ya sean internos o externos a la organización (insourcing y subcon- tratación). Los casos extremos se pueden presentar cuando diversas etapas se adjudican a organizaciones externas diferentes. Todo dependerá de las características del proyecto, de la especialización de las organizaciones externas y de los costes asociados. Como consecuencia de los anteriores párrafos, se pone de relieve la importan- cia de los entregables 6 entre etapas. La importancia de documentar los resul- tados en forma de entregables es triple: (6) En inglés, deliverables.
  • © FUOC • P08/M2104/00604 41 Implantación, proyectos y empresas de software libre • Porque la documentación de la etapa sintetiza el desarrollo y los resulta- dos. • Porque el resultado de la etapa es importante para las etapas que dependen de ella. • Porque el resultado de la etapa constituye un resultado evaluable del de- sarrollo del proyecto. Las connotaciones de ejecución interna o externa de cada etapa enfatizan la importancia de los entregables. También hay que constatar que su importancia es proporcional a la complejidad y el tamaño del proyecto. 2.1.3. La ejecución La ejecución del proyecto se iniciará según la planificación inicial propuesta y siempre con el estricto seguimiento de la organización que es objeto de la implantación del sistema. Globalmente, se puede destacar el seguimiento de tres parámetros principales: • Tiempo. El control y gestión del tiempo es fundamental para el seguimien- to del proyecto, ya que cualquier ajuste sobre este parámetro tiene con- secuencias económicas directas. También es de especial importancia para el encadenamiento de las etapas, especialmente si éstas están asignadas a equipos diferentes. • Subcontratación. El control de la subcontratación de las etapas, o even- tualmente de todo el proyecto, es importante con el fin de garantizar la adecuación del trabajo y sus resultados a los objetivos del proyecto y de la organización. Es importante poner de relieve el seguimiento y calidad de los entregables y el correcto seguimiento del calendario temporal. • Calidad. El control de la calidad de las tareas que se cumplen en la ejecu- ción del proyecto es fundamental para la calidad final de la implantación. También tiene que ser cualitativa la comunicación y la transmisión de in- formación entre el equipo que desarrolla el proyecto y la organización, con objetivos de eficiencia y eficacia. En la práctica, la ejecución de las etapas se puede ver retardada por motivos diversos, ajenos o no al proyecto y su gestión. Por ejemplo, el decalaje en la llegada del material necesario, la baja de analistas o programadores durante un periodo o la complejidad de un desarrollo que no se había previsto de manera inicial. Los retrasos acostumbran a tener una contrapartida económica. Cuando se produce un retraso, se pueden generar dos tipos de decisiones:
  • © FUOC • P08/M2104/00604 42 Implantación, proyectos y empresas de software libre • Por una parte, se puede asumir el retraso en la ejecución de la etapa, de forma que se concluya y acepte el retraso de todas las etapas que dependen de ella y, consiguientemente, del proyecto en general. • Por otra parte, se puede concluir que el retraso del proyecto no es asumible y se decide dedicar más recursos a una o más etapas para mantener la ca- dencia temporal. Sin embargo, en algunas ocasiones asignar más recursos no implica una mejora productiva proporcional a la asignación. En general, los retrasos no tendrían que afectar directamente a las etapas que se ejecutan de manera simultánea a la etapa que ha sufrido un retraso. Sin embargo, eventualmente puede resultar adecuado valorar un reajuste tempo- ral teniendo en cuenta el retraso experimentado en las otras etapas. Por ejemplo, si la implantación del sistema ha sufrido un retraso a causa de un retraso excesivo en la recepción de los materiales, se puede plantear retrasar voluntariamente la fase de formación de los usuarios con el objetivo de ajus- tarla al momento de la implantación. De esta manera, se evitaría el decalaje entre la formación de los usuarios y la aplicación de los conocimientos sobre el nuevo sistema implantado. 2.1.4. Los resultados Los resultados del ciclo de vida de un proyecto deben tener una relación directa con los objetivos estratégicos del proyecto y de la organización. El ciclo de vida en sí mismo sólo representa una forma metódica y rigu- rosa de abordar la resolución de una problemática concreta, al dividir la complejidad inherente al proyecto en diversas etapas. En cierta manera, el ciclo de vida constituye una forma adecuada de reducir el riesgo global del proyecto. La ejecución de las etapas, en forma de refina- mientos sucesivos con el fin de solucionar la problemática, contribuye a la adaptación y solución progresiva de problemas que pueden resultar de una complejidad elevada. Hay que valorar la importancia del equipo de gestión del proyecto, que con su tarea de planificación y coordinación colabora a que el proyecto se lleve a cabo con bastantes garantías de éxito. La gestión es una tarea dinámica en el tiempo y tiene que ayudar a reajustar las diferencias que se producen entre la planificación y la realidad a lo largo de la ejecución del proyecto. En general, los resultados de un proyecto de implantación de sistemas se pue- den englobar en los siguientes aspectos:
  • © FUOC • P08/M2104/00604 43 Implantación, proyectos y empresas de software libre • Organización. Para la organización, el proyecto tiene que responder a las expectativas de la actuación estratégica de la cual surge. Es de especial im- portancia poner de relieve el funcionamiento cualitativo del sistema, su integración en la metodología de la organización, la adaptación de los usuarios y la mejora competitiva de la organización. • Sistema. El sistema tiene que cumplir con todos los objetivos y expecta- tivas de la organización y tiene que responder de manera operativa a los objetivos de la actuación estratégica de la organización. El cumplimiento de los objetivos tiene que ser cualitativo en términos de eficiencia y efi- cacia funcional, tanto del propio sistema como de su interacción con los usuarios directos e indirectos. • Usuarios. El sistema tiene el objetivo de dar soporte tecnológico al funcio- namiento de la organización a través de sus usuarios. La importancia de la inclusión de los usuarios en el proyecto de implantación es estratégica, ya que sin su participación en el proceso y su aceptación del sistema, la implantación puede resultar problemática o inviable, a más de tener re- percusiones económicas. • Documentación. Como en todo proyecto, la documentación es un aspec- to fundamental para la calidad del sistema implantado, para su integración actual y evolución futura. Desde los documentos entregables entre etapas hasta la documentación final o los manuales de usuario, todos estos ma- teriales cumplen una tarea importante para el mantenimiento y soporte del sistema. • Soporte. El sistema debe tener un equipo de soporte desde el inicio del proyecto, y especialmente en las etapas de desarrollo, implantación y for- mación de los usuarios. El equipo debe permitir garantizar la interacción y la comunicación de todos los implicados en el proyecto durante y después de la implantación, bajo la forma de equipo de soporte para la formación continuada o la resolución de dudas y problemas. En cualquier caso, un proyecto de implantación de sistemas tiene que permitir que la organización y sus usuarios evolucionen hacia nuevos retos estratégicos. La creación de un clima de confianza y aceptación del cambio es fundamental para la consecución de sus objetivos. Aceptación del cambio Normalmente, este proceso se llama gestión￿del￿cambio y engloba todos aquellos as- pectos y procedimientos que tienen que permitir gestionar y solucionar las eventuales problemáticas y reticencias a la implantación de un nuevo sistema en la organización, especialmente si éste se implementa en software libre.
  • © FUOC • P08/M2104/00604 44 Implantación, proyectos y empresas de software libre 2.2. Estudio de la situación actual En este apartado se define el análisis de sistemas y se presentan las principa- les características y particularidades. Se detallan las diferentes fases que com- ponen el estudio, los principales factores que influyen en su desarrollo y los resultados que se espera obtener del análisis. El análisis de sistemas es una investigación principalmente teórica que tiene que permitir ofrecer una visión clara y precisa del estado del siste- ma de la organización, en referencia al ámbito del proyecto y de cuya actuación estratégica deriva. El análisis de sistemas se concreta en dos aspectos complementarios: • Parte del análisis se asimila a una aplicación tecnológica del estudio de un caso, con la evaluación cualitativa del sistema desde el punto de vista metodológico y procedimental. El estudio del caso El estudio del caso es un método científico que permite la exploración en profundidad de un objeto o circunstancia a través de estrategias empíricas, con el objetivo de comprender el hecho que se estudia. Normalmente se usa para la exploración inicial y en combina- ción con otras técnicas, como por ejemplo las técnicas cuantitativas (relacionadas con la estadística). • Parte del análisis se asimila al estudio de cumplimiento o competencia del sistema de la organización, con la evaluación cuantitativa del sistema desde el punto de vista funcional y tecnológico. Ved también Consultad los apartados sobre el plan estratégico de la orga- nización y el origen de la im- plantación de sistemas del pri- mer módulo para conocer más aspectos de la relación entre el proyecto de implantación y la estrategia de la organización. Las implicaciones teóricas de la investigación ponen de relieve la importancia de proceder de manera metódica, rigurosa y exhaustiva. Eventuales errores de apreciación en esta etapa pueden provocar problemas en etapas posteriores, o incluso poner en duda la continuación del proyecto a causa de sesgos entre el proyecto, el sistema actual y la estrategia de la organización, con las consi- guientes repercusiones económicas 7 . Aunque en este apartado se presentan las características del estudio inicial li- gado a un sistema ya implantando, su estructura también puede ser aplicada a proyectos de nueva implantación, trasladando el objeto de estudio al ámbito de la organización, al mercado actual e histórico, a las tendencias tecnológicas futuras y a otros proyectos similares que se hayan emprendido anteriormente. También hay que indicar que esta primera etapa del proyecto puede no tener relación directa con el software libre, ya que el objetivo es analizar y evaluar el sistema implantado o el mercado actual, sea cual sea su forma de implantación o tendencia, respectivamente. (7) No sólo es necesario tener en cuenta el coste económico direc- to de la dedicación, sino también todos aquéllos que son indirec- tos, como por ejemplo el coste de aborto de un proyecto iniciado y el coste de oportunidad que se ha perdido.
  • © FUOC • P08/M2104/00604 45 Implantación, proyectos y empresas de software libre A grandes rasgos, se pueden considerar tres grandes fases dentro del análisis de sistemas: la identificación del sistema, la preparación o desarrollo del caso de estudio y la evaluación final. 2.2.1. Identificación del sistema La identificación del sistema pretende definir el objeto, el alcance y los obje- tivos del estudio. La concreción de estos parámetros tiene una relación directa con la actuación estratégica de la cual deriva el proyecto y tiene que permitir establecer el escenario de evaluación. Hay que tener presente que un sistema ya implantado no es únicamente un conjunto de elementos tecnológicos, sino también un conjunto de funciona- lidades, métodos y procedimientos con un impacto directo en los usuarios y en la organización en general. En este sentido, es importante destacar que el alcance del estudio tiene que incluir los elementos tecnológicos de la implantación, las funcionalidades que este sistema cubre actualmente, los procedimientos y métodos de actuación que se derivan de su interacción con el funcionamiento de la organización y del impacto sobre el uso que hagan los usuarios directos e indirectos del sistema. De estos parámetros es importante determinar dos aspectos principales: • Por una parte, determinar las diferentes fuentes de información que tienen que permitir obtener los datos para el posterior análisis del sistema. • Por otra parte, identificar la naturaleza cuantitativa o cualitativa de los datos que se obtendrá de las fuentes de información, ya que las técnicas para su obtención difieren de manera sustancial. Datos cuantitativos y datos cualitativos Los datos cuantitativos son variables numéricas que cuantifican características o atribu- tos. Por ejemplo, el número de usuarios activos en el sistema por unidad de tiempo. Los datos cualitativos son variables que diferencian características o atributos, no los cuantifican. Por ejemplo, la combinación de colores de la interfaz de usuario de una aplicación. El resultado de esta fase es un documento de trabajo en el cual figura el objeto, el alcance y los objetivos del estudio, así como una relación de datos que es necesario obtener y la fuente de información asociada. 2.2.2. Desarrollo del caso de estudio Esta fase centra su actividad en la recopilación de todos los datos importantes para el estudio que se han detectado en la fase de identificación del sistema. Ved también En el apartado siguiente sobre desarrollo del caso de estudio se presentan las principales di- ferencias entre las técnicas de obtención de fuentes de infor- mación.
  • © FUOC • P08/M2104/00604 46 Implantación, proyectos y empresas de software libre La recopilación de la información puede ser muy diversa en la práctica: fuentes documentales históricas, entrevistas en detalle, resultados de auditorías tecno- lógicas, herramientas de conteo de rendimiento, documentación de proyectos anteriores, especificaciones tecnológicas, o incluso informes de incidencias. Es posible que en la recopilación de datos se denoten otros aspectos interesan- tes pero no considerados en la fase de identificación del sistema. En cualquier caso, la recogida tiene que ser rigurosa y mantener criterios de estructuración y organización en su desarrollo. Sin embargo, se pueden diferenciar dos casos genéricos para la recopilación de datos: • Datos￿cuantitativos. Normalmente, este tipo de datos se pueden recoger directamente de soportes tecnológicos. El mismo sistema implantado pue- de disponer de contadores de rendimiento, transacciones, capacidad, vo- lumen, etc., de los cuales se pueden obtener resultados estadísticos intere- santes si se consideran unidades de tiempo o de coste, por ejemplo. • Datos￿cualitativos. Normalmente, este tipo de datos se recogen de docu- mentación escrita, reuniones o entrevistas al personal. En este caso, es im- portante destacar el procedimiento de obtención de información a partir de entrevistas y reuniones, donde su preparación y ejecución minuciosa permitirá obtener información de calidad. Hay que denotar la importancia de seguir un proceso metódico que permita obtener datos tanto cuantitativos como cualitativos, ya que el sistema es una herramienta de apoyo a las personas y a la organización. Cualquier dato es importante desde el punto de vista de la evaluación y valoración del sistema. En esta fase se suele iniciar el desarrollo del inventario de hardware y software, así como el diagrama de red del sistema actual. Además de ser útil para deter- minar el estado actual, puede resultar eficiente y al mismo tiempo planificar una eventual migración del sistema. El formato final del caso acostumbra a ser un informe de investigación, donde figuran estructurados, organizados y valorados todos los aspectos que se han presentado anteriormente. Es importante que el informe justifique los datos y resultados que presenta, así como relacionarlos entre ellos y con la definición del proyecto, a la busca de posibles relaciones de dependencia o independen- cia. En función del tipo de información que se presente, puede ser útil el uso de resultados estadísticos, tablas, gráficos o diagramas y, en general, todo aquello que ayude a la presentación, comprensión y valoración de los datos que se incluyen en el informe. Ved también Encontraréis más detalles del inventario de hardware y soft- ware, y de los diagramas de red en los apartados 2.7.3 y 2.7.4 de este módulo.
  • © FUOC • P08/M2104/00604 47 Implantación, proyectos y empresas de software libre Una de las herramientas más utilizadas para la presentación de resúmenes eje- cutivos es el análisis DAFO 8 , donde se incluyen las principales conclusiones del estudio del sistema actual desde el punto de vista estratégico. Eventual- mente, y si las particularidades del proyecto lo requieren, se pueden presentar tablas DAFO que clasifiquen las diferentes características del sistema según el resultado de su evaluación; por ejemplo, si el hardware del sistema actual es una debilidad del sistema para afrontar la actuación estratégica. 2.2.3. Evaluación final La evaluación final del análisis del sistema es el primer punto de control del proyecto, y tiene el objetivo de determinar la viabilidad del sistema actual respecto de las actuaciones estratégicas de la organización y, por lo tanto, de valorar la necesidad de continuar con el proyecto. Globalmente, se pueden considerar cuatro grandes grupos de características que cabe valorar: • Operativas. Tienen relación con la interacción funcional de los usuarios con el sistema implantado, la ergonomía, el rendimiento, la eficiencia, la eficacia o la utilidad. • Organizacionales. Tienen relación con los procedimientos y métodos que ha generado el sistema implantado, y con los beneficios e inconvenientes que producen en la organización. • Funcionales. Tienen relación con la eficacia y eficiencia de las tareas que cumple el sistema implantado, la extensión, la fiabilidad, el rendimiento o los errores de funcionamiento. • Económicas￿y￿legales. Tienen relación con el coste del sistema implan- tado y la regularización legal, como el mantenimiento, las licencias o la administración del sistema. La evaluación del sistema puede generar tres grandes grupos de conclusiones: • El￿sistema￿es￿viable. El estudio y valoración concluye que el sistema ac- tual está preparado para asumir las actuaciones estratégicas de la organiza- ción. Normalmente, este tipo de conclusiones se dan en casos donde se ha emprendido un estudio para conocer el estado de un sistema grande y/o complejo, del que puede ser difícil valorar la evolución superficialmente. La evaluación positiva del sistema actual implica la cancelación del pro- yecto de implantación, ya que no se denotan indicios que requieran una nueva implantación. • El￿sistema￿es￿parcialmente￿viable. El estudio y valoración concluye que el sistema actual requiere actualizaciones menores para poder asumir las (8) DAFO son las siglas de debilida- des-amenazas-fortalezas-oportuni- dades. En inglés, SWOT.
  • © FUOC • P08/M2104/00604 48 Implantación, proyectos y empresas de software libre actuaciones estratégicas de la organización. Normalmente, los cambios se centran en la actualización o cambio de un conjunto reducido de elemen- tos, como por ejemplo el reemplazo de dispositivos o la actualización del software. La evaluación parcialmente positiva del sistema actual implica la necesi- dad de continuar con el proyecto de implantación, aunque será conve- niente revisar los objetivos y el alcance para adecuarlo a las necesidades detectadas. • El￿sistema￿no￿es￿viable. El estudio y valoración concluye que el sistema actual no puede asumir las actuaciones estratégicas de la organización. Normalmente, este tipo de conclusiones se dan en casos de migración de sistemas antiguos, que por falta de fiabilidad o rendimiento tienen que ser totalmente actualizados. La desfavorable evaluación del sistema actual implica la necesidad de con- tinuar con el proyecto de implantación de un nuevo sistema. Puede ser conveniente revisar los objetivos y el alcance del proyecto, ya que la sus- titución del sistema actual puede requerir más recursos de los previstos al inicio. Tanto el informe de análisis como la evaluación final del sistema actual son presentados a la organización por parte de la comisión de seguimiento del proyecto. Normalmente, la decisión final sobre la continuación del proyecto corresponde al órgano director de la organización. El resultado de esta etapa es doble: • Por una parte, se obtiene un informe completo del estado actual del sis- tema, donde se relevan las principales características del sistema desde el punto de vista de la estrategia de la organización. • Por otra parte, la decisión de la organización respecto de la continuación del proyecto, y las eventuales actuaciones que hay que emprender para adecuar el sistema a la estrategia de la organización. 2.3. Estudio de los requisitos de la implantación En este apartado se define el estudio de requisitos de la implantación de sis- temas y se presentan las principales características y particularidades. Se deta- llan las diferentes fases que componen el estudio, los principales factores que influyen en su desarrollo, y los resultados que se espera obtener del estudio.
  • © FUOC • P08/M2104/00604 49 Implantación, proyectos y empresas de software libre El estudio de los requisitos del sistema es un proceso por el cual se anali- za de forma metodológica la problemática que necesita ser solucionada. Los objetivos del estudio de requisitos siguen dos tendencias principales: • Definición￿de￿la￿implantación. El estudio de requisitos permite concre- tar de forma exhaustiva todas las características que tiene que tener y per- mitir el nuevo sistema a implantar. En cierta manera, define los objetivos concretos y funcionales que tiene que alcanzar la implantación. • Reducción￿del￿riesgo. El estudio de requisitos también permite reducir el riesgo del proyecto y de su gestión, concretando y refinando progresiva- mente las características de la solución a implantar. El esfuerzo que normalmente se dedica al estudio de los requisitos de un pro- yecto de implantación de sistemas es grande, por dos motivos principales: • Por una parte, porque puede resultar difícil concretar y estructurar de for- ma metodológica las ideas y esperanzas que tienen los usuarios y respon- sables de la organización sobre el nuevo sistema, teniendo en cuenta que los requisitos de usuario pueden evolucionar con el tiempo. • Por otra parte, porque es importante para el desarrollo posterior del pro- yecto, ya que cualquier error de apreciación cometido en esta fase y detec- tado en etapas posteriores tiene repercusiones económicas y temporales sobre el proyecto o costes adicionales no previstos, que pueden poner en peligro la consecución del proyecto 9 . Un requisito o requerimiento es una característica que tiene que cum- plir el nuevo sistema. Es decir, un atributo que tiene que permitir al sis- tema alcanzar los objetivos fijados. El formato de los requerimientos es habitualmente textual, pero también se pueden presentar en forma de tablas y diagramas, si ayudan a clarificar y especificar su objetivo. De forma general, se pueden definir cuatro tipos de requisitos diferentes: • Política￿estratégica. Los requisitos ligados a la política estratégica de la organización se centran en aspectos generales del proyecto, de su gestión, de su resultado, o de la tendencia que tiene que seguir. Por ejemplo, la imagen y la ética corporativa, o las características históricas propias a la organización. • Métodos￿y￿procedimientos. Normalmente, la implantación de un nuevo sistema es un buen momento para actualizar y mejorar los métodos y pro- (9) Un error cometido en las etapas de diseño del sistema, que sea de- tectado y solucionado en las eta- pas de desarrollo, puede llegar a tener una relación de coste de uno a diez.
  • © FUOC • P08/M2104/00604 50 Implantación, proyectos y empresas de software libre cesos de la organización y/o del sistema. Además de revisar de forma ex- haustiva los actuales procedimientos, también habrá que tener en cuenta la especificación de los futuros métodos y procedimientos derivados de los nuevos objetivos o funcionalidades que tendrá que cumplir el nuevo sistema. • Funcionamiento￿del￿sistema. Los requisitos de funcionamiento del siste- ma son derivados de la interacción de los usuarios con el sistema. Hay que diferenciar los requisitos funcionales de los no funcionales: los funciona- les corresponden a acciones específicas que el sistema tendrá que poder ejecutar, mientras que los no funcionales corresponden a limitaciones o restricciones al mismo tiempo que ejecutar acciones, y permiten enlazar las acciones con los métodos y procedimientos. • Factores￿clave￿y￿prioridades. La mayoría de sistemas tienen un determi- nado número de elementos principales, en cierta manera, forman parte del núcleo del sistema. En una nueva implantación, se puede dar prioridad o preferencia a aquellos componentes que se consideran indispensables para el funcionamiento del sistema y de la organización, así como otros componentes que no la tienen pueden ser considerados con una prioridad más baja.. También hay que denotar que la etapa de recogida de requisitos no tiene una relación directa con el software libre, ya que la implantación de sistemas en software libre tiene que cumplir los mismos requisitos y objetivos que cual- quier otro tipo de implantación. A grandes rasgos, se pueden considerar cinco grandes fases para el estudio de los requerimientos de un sistema: la identificación y definición, la especifica- ción y estructuración, la verificación, la validación, y la evaluación final. 2.3.1. Identificación y definición Esta primera fase del estudio de requerimientos pretende identificar y definir la problemática que se tiene que resolver y la tipología del proyecto, así como determinar las principales fuentes de información para la recogida de datos. La etapa de estudio de requisitos parte de la información documental de la etapa de análisis del estado actual, de tal forma que parte de la tarea de iden- tificación de la problemática ya está concretada previamente. Hay que identificar dentro de la organización a los implicados directos e indi- rectos, y definir el alcance de la problemática dentro de la organización, los implicados directos e indirectos, ya sean humanos, materiales, funcionales, organizacionales, procedimentales o tecnológicos. Normalmente, todos estos elementos permitirán recuperar información fundamental para la definición Ved también Consultad el apartado 1.2 del primer módulo para conocer los diferentes tipos de proyec- tos de implantación de siste- mas.
  • © FUOC • P08/M2104/00604 51 Implantación, proyectos y empresas de software libre del nuevo sistema que, conjuntamente con el informe del estado actual, per- mitirán establecer un corpus de conocimiento adecuado para la toma de de- cisiones. También es importante destacar el rol que juega la tendencia del mercado ac- tual en la definición de requisitos. Conocer las particularidades de sistemas si- milares, organizaciones del mismo sector, últimas innovaciones o tendencias futuras en la temática del proyecto, pueden ser de gran ayuda para concretar, proponer, evaluar y comprender las peticiones de los usuarios y responsables de la organización. El resultado de esta primera fase suele representarse en un documento de tra- bajo con la definición exhaustiva del objetivo y el alcance del proyecto, una relación de elementos a considerar, fuentes de información interna a la orga- nización, y una relación de elementos o tendencias de mercado susceptibles de contener información relevante para el proyecto. 2.3.2. Especificación y estructuración La fase de especificación y estructuración pretende recoger los datos relevantes de todos los elementos identificados anteriormente, y organizarlos bajo crite- rios metodológicos que permitan crear un corpus de conocimiento riguroso que represente adecuadamente la realidad. Esta fase parte del documento de trabajo elaborado en la fase anterior, con una primera aproximación a los elementos y fuentes de información susceptibles de contener información relevante para el proyecto. Sin embargo, el desarro- llo práctico del estudio puede llevar a considerar nuevas fuentes de informa- ción y nuevos aspectos relevantes para el proyecto, que no se habían tenido en cuenta en la fase anterior. Es importante investigar todos los detalles que puedan surgir en la medida en que lo permitan los plazos establecidos. Se pueden identificar dos tareas dentro del desarrollo de esta fase: • Recolección￿y￿especificación. Trata de resolver las funcionalidades del sistema. Es decir, qué hace falta que el sistema haga, no cómo lo tiene que hacer. Algunas fuentes de información tienen tendencia a centrarse en cómo realizar las acciones en lugar de determinar las particularidades de la tarea en sí misma. • Estructuración￿y￿organización. Trata de organizar los datos de forma me- tódica y comprensible. Es importante destacar que puede ser conveniente priorizar algunos requisitos antes que otros, en consonancia con los ele- mentos del sistema que son indispensables para su funcionamiento.
  • © FUOC • P08/M2104/00604 52 Implantación, proyectos y empresas de software libre De la misma forma que en el estudio de la situación actual, la recolección de los datos puede responder a criterios cuantitativos o cualitativos: • Datos￿cuantitativos. Provienen normalmente de soportes tecnológicos, y permiten el tratamiento masivo para obtener resultados estadísticos que permitan por una parte verificar y justificar los datos cualitativos, y por la otra, modelar y extrapolar resultados hacia nuevas funcionalidades. • Datos￿cualitativos. Provienen normalmente de entrevistas y reuniones con los implicados, y permiten obtener resultados funcionales y no fun- cionales respecto del sistema, así como los procedimientos y los métodos que se ven afectados por el proyecto. Los requisitos de implantación de sistemas se relacionan con los elementos básicos de todo sistema, como por ejemplo el hardware, el software, la infraes- tructura, el personal, los procedimientos, las funcionalidades, o incluso los idiomas, la documentación, los formatos y los estándares. El formato de presentación de los requisitos acostumbra a ser textual, orga- nizados según las características del proyecto, del sistema y de las particulari- dades de los mismos requisitos. También se pueden utilizar tablas, gráficos o diagramas con el objetivo de mejorar la definición, el razonamiento y la apre- ciación de los conceptos que se presentan. El resultado de esta fase suele representarse en un documento de trabajo con la presentación de todos los requisitos organizados, estructurados y justificados de acuerdo con el ideario del proyecto. La precisión y claridad de este docu- mento es fundamental para todo el proyecto, ya que no sólo depende todo el desarrollo posterior del mismo, sino también la aceptación por parte de la organización de los términos de la implantación final. 2.3.3. Verificación La fase de verificación de los requisitos pretende evaluar los requisitos recogi- dos y especificados en las fases anteriores, y valorarlos respecto de la coheren- cia como sistema y con las pretensiones de la organización. Esta fase parte del documento de trabajo de la anterior fase, que recoge de forma organizada y metódica los requisitos obtenidos en el estudio. La verificación formal de los requisitos se compone de dos grandes procesos: • Análisis￿tecnológico. El análisis tecnológico de los requisitos es un pro- ceso que pretende analizar y concluir que todos los requisitos recogidos son complementarios y que forman un sistema lógico, razonable y viable de ser implantado.
  • © FUOC • P08/M2104/00604 53 Implantación, proyectos y empresas de software libre En esta fase se suelen detectar requisitos antagónicos, fruto de las diversas fuentes de recogida de información. El conflicto se puede resolver consul- tando las otras características recogidas en los requisitos y/o validando las opciones con los implicados directos o con la organización. • Análisis￿funcional. El análisis funcional de los requisitos es un proceso que pretende analizar y concluir que el sistema que se deriva de la imple- mentación de los requisitos responde a los requisitos y objetivos del pro- yecto y de la organización. En esta fase se pueden detectar asunciones erróneas en los requisitos, que pueden ser antagónicas respecto de los objetivos del proyecto. El conflicto se puede resolver con la revisión y consulta de los aspectos problemáticos con los implicados directos y/o con la organización. El proceso de verificación de los requisitos es eminentemente tecnológico y metodológico, cuestionando la coherencia y viabilidad de la eventual imple- mentación e implantación del sistema que se define en los requisitos. Eventualmente, puede ser interesante la participación de diversas personas en la revisión de los requisitos. Los diferentes puntos de vista pueden ayudar a identificar y solucionar los posibles errores o carencias de forma más efectiva. De la revisión también pueden surgir nuevas cuestiones o situaciones que no se habían planteado hasta el momento, lo que puede inducir a un bucle en- tre la recogida de requisitos y su verificación, hasta que haya convergencia y coherencia en los resultados (proceso parecido a la metodología por refina- mientos sucesivos). Metodología top-down La metodología top-down, o por refinamientos sucesivos, parte de la definición general de la problemática y realiza un bucle especificando y desglosando cada elemento hasta que se considera un nivel de detalle suficiente y adecuado. Normalmente, el resultado se puede expresar en forma de árbol de procesos. El resultado de esta fase es una actualización del documento de trabajo con los requisitos, ya creado en la fase anterior. La actualización ha permitido la revisión en detalle de los conceptos de la implantación, además de identificar y resolver los posibles errores que podían existir en la relación de requisitos inicial. 2.3.4. Validación La fase de validación de los requisitos pretende acordar los requisitos de la implantación del nuevo sistema –fruto del estudio llevado a cabo– con la or- ganización. El acuerdo de los requisitos es la herramienta fundamental para la formalización contractual de la implantación del sistema.
  • © FUOC • P08/M2104/00604 54 Implantación, proyectos y empresas de software libre Esta fase requiere la participación activa de la organización, que tiene que ana- lizar en profundidad la propuesta de requisitos que resulta de las anteriores fases. Hay que denotar la importancia de la transmisión de información entre ambos colectivos, ya que las características de la implantación del sistema de- penden de la comprensión del estudio de requisitos. Eventualmente, el documento de trabajo interno que recoge los requisitos pue- de no ser totalmente adecuado para ser presentado al comité de seguimiento del proyecto. En estos casos, puede ser necesario crear otros documentos o presentaciones que permitan transmitir la misma información de forma más clara, efectiva y gráfica. El proceso de validación de los requisitos por parte de la organización puede concluir en nuevas revisiones de los requisitos. Normalmente, estas nuevas revisiones o refinamientos tienen relación con la adición de funcionalidades al sistema por parte de la organización, no previstas en el proyecto de forma inicial. Sin embargo, estas revisiones no pueden sucederse indefinidamente, ya que pueden afectar directamente a la viabilidad del proyecto y al calendario de la implantación, además de las implicaciones económicas que pueden tener en el aumento de los requisitos que hay que implementar. El resultado de esta fase tiene una estrecha relación con la fase de evaluación final del estudio de requisitos del sistema. Normalmente, de la fase surge la última revisión del documento de trabajo con los requisitos del nuevo sistema, acordada y validada por la organización y el equipo que ha realizado el estudio de requisitos. 2.3.5. Evaluación final La evaluación final del estudio de requisitos es el segundo punto de control del proyecto, y tiene el objetivo de determinar la viabilidad del proyecto de implantación a partir de los requisitos del nuevo sistema y, por lo tanto, de la necesidad de continuar con el proyecto. Esta fase tiene una estrecha relación con la validación de los requisitos, ya que el principal documento de trabajo es la última definición de los requisitos de la implantación del sistema, acordada por la organización. Eventualmente, las fases de validación y de evaluación final se pueden fusionar desde un punto de vista decisorio sobre la continuación del proyecto.
  • © FUOC • P08/M2104/00604 55 Implantación, proyectos y empresas de software libre La viabilidad de los requisitos del sistema se evalúa considerando su adecua- ción respecto del sistema actual, la organización, y la actuación estratégica que ha iniciado el proyecto. Con el estudio de requisitos se plasma la primera aproximación formal al nuevo sistema y las primeras apreciaciones sobre el volumen y el coste de los cambios. En cierta manera, la evaluación de los requisitos se asimila a la evaluación del estado actual, presentada en el primer apartado, donde se evalúa en términos de economía, tecnología, funcionalidad y legalidad. Sin embargo, también se pueden valorar otros aspectos relacionados con la estrategia de la organiza- ción, como por ejemplo la capacidad de evolución de la organización, los be- neficios intangibles del cambio, la calidad de la gestión o la ética corporativa. La evaluación de la propuesta de requisitos del nuevo sistema puede generar tres grandes grupos de conclusiones: • El￿proyecto￿no￿es￿viable. La valoración de los requisitos del nuevo siste- ma por parte de la organización concluye que la implantación del nuevo sistema no es viable y el proyecto se aborta. Los motivos para llegar a esta conclusión pueden ser diversos, e incluso, externos al mismo proyecto. Normalmente, esta resolución puede tener relación con la economía, la financiación, la competencia o el abandono de la estrategia que ha iniciado este proyecto. • El￿proyecto￿es￿viable￿parcialmente. La valoración de los requisitos del nuevo sistema por parte de la organización concluye que el proyecto se llevará a cabo de forma parcial, donde sólo algunos elementos del nuevo sistema serán implantados. Normalmente, esta resolución puede tener relación con la economía y la financiación. Hay que tener en cuenta que, en algunos casos, la implanta- ción parcial se puede realizar de forma progresiva o por etapas 10 . En estos casos, es importante establecer garantías de cohesión entre las diferentes implantaciones a lo largo del tiempo. • El￿proyecto￿es￿viable. La valoración de los requisitos del nuevo sistema por parte de la organización es favorable y el proyecto continúa sin limi- taciones o restricciones importantes que afecten a la definición principal del proyecto. El resultado de esta etapa es doble: • Por una parte, se obtiene un informe completo de los requisitos del nuevo sistema a implantar validado por el equipo y la organización. • Por otra parte, la decisión de la organización respecto de la continuación del proyecto y sobre el alcance de implantación del nuevo sistema. (10) Algunas organizaciones prefie- ren repartir la carga de inversión que supone una nueva implanta- ción en diferentes años contables.
  • © FUOC • P08/M2104/00604 56 Implantación, proyectos y empresas de software libre 2.4. Análisis de las soluciones en software libre En este apartado se define el análisis de las soluciones al proyecto de implan- tación y se presentan sus principales características y particularidades. Se de- tallan las diferentes fases que componen el análisis, los factores que influyen en su desarrollo, y los resultados que se espera obtener de la etapa. El análisis de soluciones es un proceso donde se analiza de forma me- tódica y rigurosa las diferentes opciones tecnológicas disponibles según los requisitos del proyecto. Los objetivos de este análisis se centran principalmente en tres aspectos com- plementarios: • Conocimiento￿del￿mercado. El análisis de soluciones permite estudiar y evaluar la situación del mercado actual en referencia a la definición, el alcance y los objetivos del proyecto de implantación. La variedad de soluciones actuales motiva un análisis en detalle y escrupuloso. • Adecuación￿de￿la￿solución. El análisis permite seleccionar las soluciones que mejor se adaptan a la problemática del proyecto y a la implantación del sistema. Además, las propiedades de apertura del código fuente inhe- rentes al software libre permiten el ajuste y adecuación final de las solu- ciones seleccionadas en forma de productos derivados. • Reducción￿del￿riesgo. El análisis de soluciones permite reducir el riesgo del proyecto y de la implantación del sistema, ya que el estudio permite adecuar la solución y controlar las principales repercusiones de su implan- tación. La etapa de análisis de soluciones en software libre se enmarca en un escenario delimitado fundamentalmente por dos condiciones: • Tipología￿del￿proyecto. La tipología del proyecto, las características y el ámbito del sistema a implantar determinarán el espectro de busca y el aná- lisis de soluciones posibles, así como la viabilidad de las diferentes pro- puestas. • Análisis￿de￿requisitos. El análisis de los requisitos del sistema tiene que determinar el comportamiento funcional y operativo de la solución hacia los objetivos del proyecto.
  • © FUOC • P08/M2104/00604 57 Implantación, proyectos y empresas de software libre Tal como se desprende de los anteriores párrafos, esta etapa parte de los do- cumentos de definición, objetivos y alcance del proyecto, así como de los re- quisitos del sistema acordados con la organización. También puede resultar interesante el informe de evaluación de la situación actual, donde se reflejarán las características, particularidades y conclusiones de la viabilidad del actual sistema. Todos ellos tienen que ayudar a centrar y focalizar las características del análisis. Esta etapa se fundamenta en la fortaleza y diversificación de la oferta en soft- ware libre del mercado actual. La busca y selección de soluciones libres que cumplan los requisitos de la implantación es básica para el proyecto de im- plantación. En este sentido, el análisis tiene que reflejar las cualidades compe- titivas del software libre respeto soluciones privativas, considerando especial- mente las libertades de uso y adecuación del código fuente. A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa de análisis de las soluciones en software libre: la búsqueda de las soluciones, el análisis y valoración de los candidatos, y la evaluación final. 2.4.1. Búsqueda de las soluciones Esta primera fase de búsqueda pretende identificar soluciones plausibles de ser implantadas en el marco del proyecto. Se trata de realizar una primera selección de sistemas cuyo objetivo se aproxime a los objetivos del proyecto. El software libre constituye una opción válida y viable para la implantación de sistemas, permitiendo un amplio abanico de libertades sobre el uso, la ex- plotación, el acceso y modificación al código fuente, y el licenciamiento de los derivados. Estas características no sólo permiten su uso libre en organizaciones y parti- culares, sino también permiten la independencia de los proveedores propie- tarios, el ahorro en licencias y royalties, aprender del código fuente original, controlar la obsolescencia con garantías de mantenimiento, calidad y fiabili- dad del producto, o garantizar aspectos de seguridad, privacidad, interopera- bilidad y convergencia del software. Históricamente, se pueden destacar dos ámbitos principales en la implanta- ción del software libre: • Implantación en servicios de infraestructura 11 Desde sus inicios, el software libre ha tenido una relación muy estrecha con la arquitectura de sistemas y los servicios de red. Actualmente, lidera sobradamente algunos sectores 12 ante el software propietario. • Implantación en clientes o usuarios domésticos 13 (11) Por ejemplo, los servidores de una red local forman parte de los servicios de infraestructura básica de la organización.
  • © FUOC • P08/M2104/00604 58 Implantación, proyectos y empresas de software libre Con el paso del tiempo, y gracias a iniciativas de diferente orden, el soft- ware libre se ha extendido hacia el entorno de usuario final, habiendo iniciado una nueva trayectoria ante los estándares de facto en el entorno doméstico. (12) Por ejemplo, la implantación de Apache Web Server en servidores web es superior respecto de otros entornos. (13) Por ejemplo, la distribución Ubuntu compete directamente contra el sistema operativos de Mi- crosoft, rompiendo muchos mitos sobre la dificultad de la instalación, la gestión o el uso de los entornos GNU/Linux. Con todo ello, el mercado actual dispone de una amplia variedad de sistemas en software libre en campos muy diversos. La mayoría de proyectos importan- tes disponen de portales en Internet, que permiten el conocimiento, la difu- sión, la descarga y la colaboración con el proyecto 14 . Sin embargo, también existen depósitos públicos 15 que permiten la creación, el desarrollo y la colaboración en nuevos proyectos relacionados con el software libre, así como la descarga de los productos resultantes. Los depósitos actúan en muchos casos de plataforma de lanzamiento para proyectos comunitarios. Hay que considerar que es posible que no exista una solución única para el proyecto de implantación, ya sea por alcance o por especialización de los ob- jetivos. En estos casos, hay que categorizar la busca de soluciones en tipologías más genéricas, de tal modo que diversos sistemas especializados puedan coo- perar para dar una solución conjunta a los requisitos del proyecto 16 . (16) Por ejemplo, si se busca una solución para la gestión de una base de datos vía web, puede resultar factible buscar separadamente un sistema operativo, un servidor web, un gestor de bases de datos y una herramienta de programación que puedan cooperar para ofrecer las funcionalidades exigidas. Éste es el caso del entorno LAMP (Linux, Apache, MySQL i PHP), de gran difusión actualmente. De la búsqueda de soluciones se tiene que obtener un documento con los re- sultados de la investigación. Este documento tendría que contener los siguien- tes aspectos: • Definición￿e￿identificación￿de￿la￿búsqueda￿de￿soluciones. Establece las características que han guiado la búsqueda, denotando la relación con la definición del proyecto, objetivos y alcance, así como con la definición de los requisitos que se han acordado. • Lista￿de￿soluciones. El documento tiene que contener una lista de las soluciones encontradas en el proceso de búsqueda, estableciendo en cada caso una breve definición de la solución y la relación con los objetivos del proyecto. • Ficha￿técnica￿de￿soluciones. La ficha técnica de cada solución tiene que permitir conocer las principales características del sistema, como por ejem- plo la definición del proyecto, los depósitos donde se encuentra, el segui- (14) Por ejemplo, la distribución Ubuntu (www.ubuntu.com), la suite ofimàtica OpenOffice.org (www.openoffice.org) o la suite de navegación Mozilla (www.mozilla.org). (15) Por ejemplo, SourceForge.net (sourceforge.net).
  • © FUOC • P08/M2104/00604 59 Implantación, proyectos y empresas de software libre miento y mantenimiento del producto, los idiomas que soporta, la cola- boración comunitaria, la licencia final y otros requisitos inherentes al pro- ducto, como la ergonomía de uso, los requisitos de ejecución y las princi- pales funcionalidades. En caso de que no existan soluciones únicas para la problemática que presen- ta el proyecto y sea necesario la categorización en diferentes soluciones indi- viduales, el documento se podrá estructurar en categorías por tipología (por ejemplo, sistemas operativos o suites de ofimática) o por función (por ejemplo, un servidor de base de datos con interfaz web de acceso y programación). En algunos casos, se presenta de forma adicional una tabla DAFO para cada una de las opciones localizadas. Esta tabla tiene especial relevancia en las reuniones y decisiones ejecutivas, y su objetivo es identificar y sintetizar las principales características, ventajas e inconvenientes inherentes a su adopción. 2.4.2. Análisis y valoración de los candidatos La fase de análisis y valoración de los candidatos pretende identificar las so- luciones más adecuadas al proyecto y a la organización, pero también a las particularidades del desarrollo, la implantación y la migración. Esta fase parte del documento de la fase anterior, en el cual se listan las solu- ciones actuales más indicadas para el proyecto y se detallan las principales ca- racterísticas. Se trata de seleccionar de manera metódica y rigurosa a los mejo- res candidatos para la implantación de entre las diferentes alternativas iden- tificadas. Normalmente, se analiza, se pondera y se evalúa un conjunto determinado de parámetros tecnológicos relacionados directamente con el proyecto, la or- ganización y el proceso de implantación. La valoración individual llevará a establecer una clasificación ordenada que determinará la adecuación de cada solución al proyecto de implantación. De manera general, se pueden considerar los siguientes parámetros para la evaluación y valoración de una solución: • Proyecto￿y￿organización. Hay que valorar la adecuación a los objetivos del proyecto, la organización, la definición de los métodos y procedimien- tos, la ética y estándares históricos de la organización y la actuación estra- tégica que ha emprendido el proyecto. • Sistema￿e￿interoperabilidad. Hay que valorar la adecuación a las necesi- dades del sistema y que garantice el funcionamiento con la dotación de recursos de hardware, software y red actual o futura, la factibilidad de los métodos y procedimientos, la implementación de la actuación estratégica,
  • © FUOC • P08/M2104/00604 60 Implantación, proyectos y empresas de software libre la interoperabilidad con otros sistemas existentes y estándares de la orga- nización y las posibilidades de ampliación y evolución futura. • Funcionalidad￿y￿ergonomía. Hay que valorar la adecuación a las nece- sidades funcionales y operativas del proyecto y de la organización y que garantice la ergonomía de su utilización, implemente los métodos y pro- cedimientos con garantías de funcionamiento y responda a las esperanzas de los usuarios y de la organización. • Eficiencia￿y￿rendimiento. Hay que valorar que garantice un funciona- miento eficiente en todo momento, el aprovechamiento y el rendimiento de los recursos dedicados y el mantenimiento de un equilibrio adecuado entre recursos y rendimiento a lo largo del tiempo, que permita la evolu- ción. • Eficacia￿y￿fiabilidad. Hay que valorar que garantice el cumplimiento de las funciones establecidas en los objetivos del proyecto, que mantenga el cumplimiento funcional de los objetivos en todo momento, que manten- ga también el equilibrio entre recursos y el cumplimiento a lo largo del tiempo y que permita la evolución. • Implantación￿y￿migración. Hace falta valorar la adecuación al proceso de implantación del sistema y que permita la migración eficiente y eficaz a partir de un sistema anterior, minimice las consecuencias de impacto en el funcionamiento habitual de la organización y garantice herramientas de soporte, formación y adaptación de los usuarios y de los otros sistemas existentes. • Mantenimiento￿y￿gestión. Hay que valorar que garantice que el sistema disponga de herramientas de gestión y configuración adecuadas a los ob- jetivos del proyecto, minimice las operaciones de mantenimiento físicas y lógicas, garantice el equilibrio entre funcionamiento y mantenimiento a lo largo del tiempo, y permita la evolución. • Soporte￿y￿compromiso. Hay que valorar que garantice el soporte y segui- miento de sus creadores con el sistema y con sus usuarios y que ayude al compromiso de la comunidad en la evolución y mejora futura y, en ge- neral, a todos aquellos aspectos que puedan suponer la obsolescencia del sistema y la resolución de problemas. • Licencias. Hay que valorar que garantice el cumplimiento de la legalidad vigente, establezca el escenario de uso y explotación, permita la distinción clara y efectiva de las actuaciones que se pueden llevar a cabo con el siste- ma y especifique las licencias de los eventuales productos derivados. • Economía. Hay que valorar la adecuación a la economía de la organiza- ción, a la financiación prevista del proyecto, a los costes de gestión, man-
  • © FUOC • P08/M2104/00604 61 Implantación, proyectos y empresas de software libre tenimiento y funcionamiento eficiente y eficaz a lo largo de la vida pre- vista del sistema y también a los costes de formación y educación de los usuarios del sistema. Tal como se desprende de la lista anterior, los parámetros buscan la valoración de los candidatos en diferentes ámbitos (tecnológico, estratégico, operativo, económico, etc.), con el objetivo de profundizar, analizar y valorar el impacto de la eventual implantación en la organización. El resultado de esta fase es un documento que clasifica y pondera de manera numérica los diferentes candidatos (eventualmente por categorías) y ordena las soluciones por grado de adecuación al proyecto y a la organización. Sin embargo, es posible que se produzcan empates técnicos entre diferentes soluciones, es decir, que haga falta un estudio adicional entre alternativas que, a pesar de diferir en sus características, presentan adecuaciones similares para el proyecto. En estos casos, puede ser útil implementar una tabla DAFO de cada solución, con el objetivo de hacer surgir diferencias que puedan ayudar a la elección final. 2.4.3. Evaluación final La evaluación final del análisis de soluciones en software libre es el tercer pun- to de control del proyecto y tiene el objetivo de determinar el desarrollo del proyecto de implantación, es decir, la forma que tomará el proyecto y su im- plementación final. Esta fase parte de los documentos de la fase anterior, que contienen una clasi- ficación de las soluciones existentes según su adecuación al proyecto, así como las fichas técnicas y/o tablas DAFO que las analizan en profundidad. Esta fase trata de cumplir dos objetivos principales: • Selección￿final￿de￿candidatos. Aunque la fase anterior ya propone indi- rectamente las soluciones más adaptadas al proyecto y a la implantación (mediante la puntuación y la clasificación), puede convenir evaluar adi- cionalmente la integración global de todas las soluciones. • Desarrollo￿del￿proyecto. La selección de las soluciones que satisfacen los requisitos del proyecto comportarán consecuencias directas en su desarro- llo, por ejemplo en su coste temporal y económico. Es importante destacar que los componentes del sistema no estarán desaco- plados entre sí, por lo que se deberán hallar las mejores soluciones que gene- ren un sistema estable y operativo, además de cumplir con los requisitos del proyecto.
  • © FUOC • P08/M2104/00604 62 Implantación, proyectos y empresas de software libre En algunos casos, puede resultar útil realizar pruebas de integración que per- mitan determinar la calidad y rendimiento de la cohesión de los diferentes elementos, ya que la integración de diversas soluciones altamente puntuadas en sus respectivas categorías no garantiza que el comportamiento global esté al mismo nivel 17 . Con respecto al desarrollo del proyecto, la elección de las soluciones comporta ajustes en el proyecto, especialmente en la fase de desarrollo. Globalmente, se pueden considerar tres tipos diferentes de implantación: (17) Por ejemplo, si el conector de los dos sistemas no es eficiente o está limitado por la compatibilidad con otros sistemas. • Implantación￿directa. Las soluciones que más se ajustan a las necesidades del proyecto y de la organización se pueden implantar de manera directa, ya sea porque son de uso general o porque los objetivos del proyecto res- ponden a las necesidades específicas de un colectivo grande. En cualquier caso, las diferencias entre los requerimientos del proyecto y las funcionalidades de la solución no son determinantes para rechazar la adopción. • Evolución￿de￿la￿solución. Las soluciones que más se ajustan a los reque- rimientos del proyecto y de la organización únicamente presentan dife- rencias significativas en puntos concretos. Su adopción requiere una evo- lución del código fuente para ajustar las carencias que pueda tener la so- lución original ante las incidencias del sistema. Gracias a las libertades que ofrece el software libre, ésta es una opción vá- lida y viable en la práctica, mientras que la alternativa en software propie- tario posiblemente requiriría un desarrollo completamente nuevo, con las implicaciones económicas que ello comporta. • Desarrollo￿nuevo. No existen soluciones que se ajusten con suficiencia a las incidencias del proyecto y de la organización, por lo que será necesario un desarrollo completamente nuevo con el fin de solucionar la problemá- tica. Estos casos se pueden dar en sistemas con requerimientos muy especializa- dos, como la robótica. En casos extremos, es posible que tampoco existan soluciones de propiedad en los canales habituales de comercialización. En cualquier caso, la libertad de estudiar, analizar y reutilizar el código fuente del software libre permite mejorar la calidad, eficiencia y eficacia del nuevo desarrollo y abaratar los costes asociados. La evaluación de las soluciones en software libre puede conducir a tres grandes tipos de conclusiones: Soluciones de implantación directa Ejemplos de soluciones de im- plantación directa pueden ser sistemas operativos, paquetes de ofimática, clientes de co- rreo electrónico o navegadores web. • Proyecto￿viable￿de￿implantación￿directa. El proyecto es viable y los re- quisitos de la implantación se pueden resolver con soluciones existentes. (18) Por ejemplo, la sustitución del software MS Word por OpenOffice.org, en el que las dife- rencias funcionales se pueden su- plir con la formación de los usua- rios.
  • © FUOC • P08/M2104/00604 63 Implantación, proyectos y empresas de software libre Las eventuales diferencias entre las soluciones que se tienen que implantar y las incidencias del proyecto no son insalvables 18 . • Proyecto￿viable￿con￿condiciones. El proyecto es viable, pero los requisi- tos de la implantación requiere emprender un proceso de creación o adap- tación de soluciones. Las implicaciones temporales y económicas vendrán dadas por el alcance del proceso, que será máximo cuando sea necesario un desarrollo completamente nuevo. • Proyecto￿inviable. Aunque en esta etapa no es habitual abortar el proyec- to, se pueden dar casos en que la organización no quiera continuar con él. Por ejemplo, por la falta de financiación para afrontar un desarrollo concreto o cambios en la estrategia de la organización. El resultado de esta etapa es doble: • Por una parte, obtendremos las soluciones en software libre más adaptadas a los requerimientos del proyecto y de la organización. • Por otra parte, obtendremos una valoración preliminar de los costes rela- cionados con la etapa de desarrollo del proyecto (implantación directa o necesidad de un desarrollo adicional). 2.5. Formalización de la propuesta En este apartado se define la formalización de la propuesta del proyecto de implantación y se presentan las principales características y particularidades. Se detallan las diferentes fases que componen el proceso, los principales fac- tores que influyen en su desarrollo y los resultados que se pueden obtener de la etapa. La formalización de la propuesta es la etapa del proyecto donde se con- cretan, se especifican y se enlazan todos los resultados obtenidos en las primeras fases metodológicas del proyecto –llamadas etapas de diseño–, con el objetivo de proponer una solución formal a la problemática de implantación de sistemas de la organización. Los objetivos específicos de esta etapa se centran principalmente en tres as- pectos: • Caracterización￿del￿proyecto. La formalización de la propuesta reúne, clarifica y relaciona todos los resultados de las primeras etapas del diseño de la implantación de sistemas. El resultado de esta etapa tiene que servir
  • © FUOC • P08/M2104/00604 64 Implantación, proyectos y empresas de software libre de guía para el desarrollo posterior de la implantación, por lo cual se hace notar su importancia dentro del proyecto. • Validación￿por￿parte￿de￿la￿organización. La formalización de la propues- ta también sirve para presentar y evaluar el proyecto de implantación por parte de la organización. La valoración que resulta concreta el futuro del proyecto, su viabilidad y su desarrollo y ejecución. • Reducción￿del￿riesgo. La formalización de la propuesta permite reducir el riesgo del proyecto y de la implantación del sistema y delimita el escenario de evolución del proyecto gracias a la concreción de las soluciones y del desarrollo de la implantación. Esta etapa guarda relación con la gestión funcional del proyecto porque per- mite concretar aspectos de la planificación del proyecto como la gestión de los tiempos, los recursos y el coste del proyecto, considerando la información que se obtiene a partir de los resultados de las etapas anteriores. Globalmente, la propuesta tiene que dar respuesta a dos aspectos principales: • Aspectos￿metodológicos. Los aspectos metodológicos hacen referencia a los resultados de las etapas de análisis y diseño de la implantación de sis- temas, vistas en esta unidad. Más concretamente, el análisis del sistema actual, el análisis de requerimientos y el análisis de soluciones en software libre. El objetivo es plasmar las características del sistema que se tiene que implantar como resultado de un proceso metódico y riguroso. • Aspectos￿de￿gestión. Los aspectos de gestión hacen referencia a las parti- cularidades de funcionamiento y ejecución del proyecto, como la planifi- cación temporal, la económica o la relativa a los recursos humanos que harán falta para llevar a término el proyecto. El objetivo es plasmar los parámetros de ejecución del proyecto, ofreciendo una visión clara de los requisitos necesarios con el fin de alcanzar los objetivos. De los anteriores párrafos podemos concluir la importancia de la comunica- ción y la colaboración con la organización, con el objetivo de transmitir co- rrectamente toda la información relevante del proyecto. Globalmente, se pue- den identificar dos aspectos principales de la información que hay que trans- mitir: • El￿proyecto. La comprensión del proyecto, de los resultados obtenidos en el análisis y de la solución más adecuada a las características del proyecto. Es importante que quede clara la relación entre las propuestas del proyecto y la actuación estratégica que persigue la organización. • El￿software￿libre. La comprensión de la utilización del software libre, el modelo filosófico en el cual se sustenta y las características de las licencias, Ved también Consultad éstos y otros aspec- tos de la gestión de proyectos en el apartado de "Gestión de proyectos en software libre" de la primera unidad.
  • © FUOC • P08/M2104/00604 65 Implantación, proyectos y empresas de software libre así como las particularidades de las soluciones propuestas y los beneficios que obtiene la organización. A grandes rasgos, se pueden considerar cuatro grandes fases dentro de la for- malización de la propuesta: la preparación, el diseño, la presentación y la eva- luación final. 2.5.1. Preparación de la propuesta Esta primera fase de formalización de la propuesta pretende recuperar todas las informaciones plausibles de ser incorporadas en la propuesta de solución. Se trata de obtener los documentos de resultado de las diferentes etapas de estudio y análisis, así como de la planificación del proyecto. Uno de los principales objetivos de esta primera fase es generar resultados avanzados a partir de los datos iniciales. Es decir, crear resúmenes, esquemas, tablas, diagramas o gráficos que permitan clarificar los conceptos de los docu- mentos técnicos que se han desarrollado a lo largo del proyecto. Otro resultado que se obtiene de esta primera fase es la actualización de la pla- nificación del proyecto a partir de la información contenida en los diferentes documentos de análisis. Normalmente, los aspectos más importantes para la organización son: • Solución￿a￿implantar. Es importante la definición de la solución que se quiere implantar, los objetivos y el alcance del proyecto, las incidencias estratégicas a las que da solución y los sistemas que serán implantados. • Coste￿temporal. El coste temporal tiene relación con la planificación tem- poral de los recursos y de la propia implantación o migración. Ved también Consultad el apartado "Ges- tión del tiempo" para conocer más aspectos del coste tempo- ral del proyecto. • Coste￿económico. El coste económico tiene relación con la repercusión económica que resulta de implantar el sistema en la organización (mate- rial, recursos, tiempo, formación, etc.) y de la gestión del proyecto (equi- po de gestión del proyecto). Hay que tener presente que debe valorarse el coste económico del proyecto desde sus inicios19 . Eventualmente, también puede resultar útil preparar los siguientes aspectos: • Buscar mitos históricos del software libre, especialmente de las soluciones propuestas, y argumentar a favor y en contra. El objetivo es ofrecer una base de trabajo con el fin de justificar y fundamentar la propuesta ante las eventuales reticencias al cambio20 que se puedan observar en su pre- sentación. Ved también Consultad el apartado "Ges- tión del coste" con el fin de co- nocer más aspectos del coste económico del proyecto. (19) Tal como se desprende del apartado "Recursos de un proyec- to de implantación de sistemas", el proyecto se inicia cuando se dota de recursos por primera vez. (20) En inglés FUD (fear, uncertainty and doubt).
  • © FUOC • P08/M2104/00604 66 Implantación, proyectos y empresas de software libre • Obtener y presentar información de tipologías de licencia en software li- bre, con el objetivo de desmitificar algunas asunciones y transmitir con fundamentos la filosofía libre y su relación con la solución propuesta. • Crear tablas DAFO para representar y justificar situaciones en que ha sido necesario tomar decisiones a partir del estudio y la evaluación de diferentes opciones. En estos casos, puede ser conveniente evaluar y ponderar cada una de las alternativas que se presentan. De esta fase se obtiene un conjunto de documentos con resultados sobre dos aspectos principales: • Por una parte, un conjunto de referencias a documentos técnicos de aná- lisis de las etapas de diseño, así como diversos resultados avanzados e in- formación relacionada con el proyecto y el software libre. • Por otra parte, una actualización de la planificación de la gestión del pro- yecto, que incluirá todos los aspectos derivados de las etapas de análisis y diseño, que modelan la continuación del proyecto. 2.5.2. Diseño de la propuesta La fase de diseño de la propuesta pretende confeccionar todos aquellos docu- mentos y presentaciones que deben presentarse a la organización y que resu- men el trabajo realizado en las etapas de estudio y análisis del proyecto de implantación de sistemas. Esta fase parte de los documentos de la fase anterior, con referencias a docu- mentos técnicos, información relacionada con el proyecto y con el software libre, resultados avanzados y actualización de la planificación temporal y eco- nómica. Se trata de estructurar, organizar y presentar toda la información dis- ponible a fin de que sirva de guía para el posterior desarrollo del proyecto. Globalmente, se pueden llegar a generar dos grandes tipos de documentos diferentes: • Informes￿y￿planificaciones: son documentos que presentan los resulta- dos de un estudio profundizado. Su objetivo es presentar los contenidos de manera estructurada y metódica, con precisión, orden y rigor, a fin de que sean utilizados como guía o manual del proyecto. • Presentaciones: son documentos que muestran el estudio en líneas gene- rales. Su objetivo es presentar los principales conceptos del estudio de ma- nera ordenada, sintética y gráfica, a fin de que sean utilizados como resu- men del proyecto.
  • © FUOC • P08/M2104/00604 67 Implantación, proyectos y empresas de software libre Los informes tienen que presentarse editados y compaginados, utilizando un lenguaje formal y riguroso. Normalmente, un informe contiene los siguientes elementos: • Resumen￿ejecutivo: es un resumen breve, que ubica el proyecto de im- plantación de sistemas y su contenido en el tiempo, en el espacio, en los objetivos y en las soluciones. • Introducción: presenta la situación estratégica de la organización y la ne- cesidad de emprender un proyecto de implantación de sistemas en unas circunstancias concretas. • Análisis￿de￿la￿situación￿actual: tiene que presentar un resumen del estu- dio, el análisis y las conclusiones del sistema actual de la organización en relación a su estrategia. • Definición,￿objetivos￿y￿alcance: se presenta el proyecto de implantación de sistemas, los conceptos generales de la solución que se propone, la jus- tificación del uso del software libre y su adecuación a la estrategia de la organización. • Arquitectura￿del￿sistema,￿infraestructura￿y￿tecnología: presenta la ar- quitectura general y funcional del sistema, la infraestructura que requiere, la tecnología y los estándares que utiliza, así como las licencias finales. Eventualmente se pueden presentar pruebas de integración de los diferen- tes elementos. • Recursos￿humanos￿y￿materiales: se presentan los recursos humanos y materiales necesarios para el funcionamiento habitual del sistema dentro de la organización. • Implantación￿y￿mantenimiento: presenta la metodología de implanta- ción que se seguirá, las características de la migración, la formación de los usuarios, la adaptación de la organización y el mantenimiento necesario de la instalación a lo largo del tiempo (normalmente, a un plazo de cinco años). • Planificación￿temporal: detalla el seguimiento y la relación de las etapas del proyecto a lo largo del tiempo, con la cosideración de los recursos asig- nados en cada momento. Normalmente, también se presenta un gráfico donde se representan las etapas en función del tiempo. • Planificación￿económica: presenta la valoración del coste de llevar a cabo el proyecto, desglosando las diferentes partidas que componen el coste de la implantación (por ejemplo, coste de la gestión de los proyectos, recursos
  • © FUOC • P08/M2104/00604 68 Implantación, proyectos y empresas de software libre humanos necesarios, gastos de material, desarrollo y ajuste de software, instalación de infraestructura). • Sinergias￿con￿la￿comunidad￿de￿software￿libre￿y￿con￿otros￿proyectos￿u organismos: eventualmente, y según las características de la organización, se incluye un apartado que explica la relación de las soluciones utilizadas con el mundo de la filosofía libre, el aprovechamiento de otros proyectos similares y la relación con otros organismos o con la comunidad de soft- ware libre. • Conclusiones: hay que poner énfasis en las características del proyecto que solucionan las necesidades estratégicas de la organización y los bene- ficios que se obtienen del uso del software libre. • Anexos￿técnicos: pueden ser útiles para el desarrollo posterior del proyec- to. Por ejemplo, el análisis de los requerimientos del sistema. De esta fase se obtienen dos documentos: • El informe o plan de proyecto, que se presentará como documentación técnica del proyecto. • La presentación, que servirá a la reunión ejecutiva de la fase siguiente. 2.5.3. Presentación de la propuesta En esta fase se presenta la propuesta a la organización, normalmente enmarca- da dentro de una reunión ejecutiva con su órgano directivo. El objetivo con- siste en poner en conocimiento de la organización los resultados finales de las etapas de análisis, a fin de que puedan valorar la propuesta de solución y el seguimiento del proyecto, así como evaluar su continuidad. Normalmente, esta fase se implementa presentando todos los aspectos del pro- yecto de manera gráfica y resumida, utilizando el documento de presentación de la fase anterior. De manera adicional a la presentación, se hace entrega del plan de proyecto con los resultados de las etapas de diseño. En esta fase es de especial importancia poner de relieve la comunicación y la transmisión de la información, destacando la relación de la propuesta con los objetivos estratégicos de la organización. Aunque no es habitual, eventual- mente se puede pedir la reformulación de algunos aspectos de la propuesta, que, en cualquier caso, tendrían que ser de poco alcance cuantitativo y cua- litativo.
  • © FUOC • P08/M2104/00604 69 Implantación, proyectos y empresas de software libre Es posible que la comisión que tiene que decidir la implantación del sistema muestre reticencias al uso del software libre, por lo cual puede convenir jus- tificar la propuesta desmitificando algunas ideas preconcebidas, presentando las ventajas e inconvenientes de su uso o, incluso, la filosofía libre en gene- ral y los modelos de licencia. Puede resultar útil el documento realizado en la fase de diseño de la propuesta sobre temas relacionados con el proyecto y el software libre. Esta fase tiene especial relación con la fase siguiente, de evaluación final, ya que a menudo las reuniones de presentación son decisorias con respecto a la continuación del proyecto. 2.5.4. Evaluación final La fase de evaluación final de la formalización de la propuesta es el cuarto pun- to de control del proyecto y tiene como objetivo valorar el trabajo realizado en las etapas de diseño de la implantación, así como la propuesta de solución al proyecto. También tiene el objetivo de resolver la viabilidad y continuidad del proyecto para las etapas de desarrollo e implantación del sistema. Esta fase tiene una estrecha relación con la anterior, ya que la presentación del plan de proyecto y el intercambio de información entre el equipo que ha realizado el diseño y la organización es fundamental para considerar todas las implicaciones de la solución presentada. Eventualmente, las fases de presen- tación y validación de la propuesta se podrían fusionar desde el punto de vista decisorio sobre la continuación del proyecto. La importancia de este punto de control es doble: • Por una parte, porque con la formalización de una propuesta se cierra el ciclo teórico y conceptual de análisis y diseño del sistema y del proyecto de implantación que lleva asociado. Las etapas siguientes serán principal- mente prácticas. • Por otra parte, porque la organización determinará si el proyecto se com- pletará finalmente y dará respuesta a la actuación estratégica que lo ini- ció, con la implantación del conjunto de cambios que se consideran en la propuesta. En este sentido, y tal como ya se ha comentado en anteriores apartados, la or- ganización tiene que valorar los aspectos del proyecto que considere adecua- dos a su estrategia; por ejemplo, las características de la solución que se quiere implementar, el coste temporal con el fin de realizar la implantación y el coste económico del proyecto y de la implantación del sistema.
  • © FUOC • P08/M2104/00604 70 Implantación, proyectos y empresas de software libre También puede ser un buen momento para analizar, valorar y adecuar algunos detalles inherentes a la implantación del sistema en la organización, conside- rando y concretando algunos aspectos de la gestión del cambio, el calendario de la implantación, las pruebas piloto o la formación de los usuarios. La evaluación de la propuesta por parte de la organización puede acabar en tres grandes tipos de decisiones: • Proyecto￿viable. La organización acepta la solución propuesta sin cam- bios importantes en sus especificaciones. Los eventuales ajustes pueden hacer referencia al calendario de la implantación o la inclusión de algunas partidas económicas, por ejemplo. • Proyecto￿viable￿con￿condiciones. La organización considera que se ne- cesitan ajustes en la propuesta de solución. Los cambios pueden ser de mayor o menor consideración, pero en cualquier caso habrá que rehacer una parte de la propuesta si se quiere que el proyecto siga adelante. Estos cambios pueden tener relación con las herramientas implantadas o con la ejecución parcial del proyecto, por ejemplo. • Proyecto￿no￿viable. La organización considera que el proyecto no es via- ble y se aborta la implantación del sistema. Aunque no es habitual que pase en esta etapa del proyecto, un cambio drástico en la estrategia de la organización o la incapacidad para asumir económicamente la finaliza- ción del proyecto pueden ser causas plausibles del aborto prematuro de la implantación. El resultado de esta etapa es doble: • Por una parte, se obtiene el plan de proyecto, acordado y validado con la organización. • Por otra parte, se obtiene la decisión sobre la continuación e implementa- ción del proyecto. 2.6. Desarrollo En este apartado se define la etapa de desarrollo del proyecto de implantación y se presentan las principales características y particularidades. Se detallan las diferentes fases que componen el proceso, los principales factores que influyen en su desarrollo y los resultados que se espera obtener de la etapa.
  • © FUOC • P08/M2104/00604 71 Implantación, proyectos y empresas de software libre El desarrollo del sistema es la etapa en que se implementan las solucio- nes que se especifican en el plan de proyecto, así como todos los re- quisitos relacionados con su puesta en marcha. El objetivo principal es adecuar, recolectar y producir todos los elementos necesarios con el fin de realizar la implantación con el máximo de garantías de eficiencia y eficacia, minimizando el tiempo de intervención. Esta etapa parte de los documentos de la etapa anterior, principalmente el plan de proyecto y el análisis de requerimientos del sistema que se quiere implantar. Estos documentos son fundamentales para preparar, estructurar y organizar el desarrollo de todos los componentes necesarios para implantar el proyecto. Los objetivos específicos de esta etapa se centran principalmente en dos as- pectos: • Implementación￿de￿la￿solución. El desarrollo pretende implementar la solución que determina el plan de proyecto y el estudio de los requeri- mientos, independientemente de la forma que tome el tipo de desarrollo. • Reducción￿del￿riesgo. El desarrollo también pretende reducir el riesgo global del proyecto, preparando, concretando y construyendo la solución sin afectar directamente al funcionamiento de la organización. Globalmente, el desarrollo tiene que dar respuesta a dos aspectos principales: • Aspectos￿metodológicos. Los aspectos metodológicos hacen referencia a la tipología del proyecto, por lo cual la etapa de desarrollo tiene una rela- ción directa con el objeto de la implantación. Es decir, la metodología de desarrollo que habrá que aplicar dependerá del objetivo del proyecto. Ved también En el apartado "Verificación de los requerimientos" de es- te módulo se han presentado tres tipologías de proyecto: la implantación directa, la evolu- ción de herramientas existen- tes y el desarrollo de una nue- va solución. Ved también Consultad el apartado 1.2.2 "Clasificación por objetivo de los proyectos" con el fin de co- nocer las diferentes tipologías de proyectos en función del objetivo. • Aspectos￿de￿gestión. Los aspectos de gestión hacen referencia a los impli- cados en el desarrollo, es decir, a los encargados de implementar las tareas que se recogen en el plan de proyecto. A grandes rasgos, se puede consi- derar un desarrollo interno (insourcing) o externo (outsourcing). A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa de desarrollo: la dotación de recursos, la configuración o desarrollo de software y la evaluación final, aunque la existencia individual de estas etapas depende en gran medida de la tipología del proyecto. Ved también Consultad el apartado "Recur- sos de un proyecto de implan- tación de sistemas" de la pri- mera unidad con el fin de co- nocer más aspectos del desa- rrollo interno y externo.
  • © FUOC • P08/M2104/00604 72 Implantación, proyectos y empresas de software libre Hay que precisar que las fases de dotación de recursos y desarrollo de softwa- re se pueden ejecutar de manera simultánea en el tiempo, en función de la tipología del proyecto. También es posible que la superposición temporal sea sólo parcial, a causa de diferencias en el calendario de entrega de los diferentes recursos, por ejemplo. También hace falta tener en cuenta que la etapa de desarrollo guarda una es- trecha relación con la siguiente, la de implantación o migración del sistema. En este caso, eventualmente también se puede producir la superposición o si- multaneidad temporal de algunas tareas con el fin de reducir el calendario del proyecto, aunque puede tener consecuencias económicas que hay que valorar, como la necesidad de más recursos humanos y materiales, por ejemplo. 2.6.1. Dotación de recursos Esta primera fase de dotación de recursos pretende seleccionar y adquirir todos los recursos necesarios para la implantación del sistema en la organización. Se trata de obtener todos aquellos elementos que tienen una relación de prerre- quisito directa para la implantación y explotación del nuevo sistema. Uno de los principales objetivos de esta primera fase es dotar la organización de la infraestructura necesaria con el fin de poner en funcionamiento el sistema. Es decir, todos aquellos recursos materiales, organizaciones y configuraciones que tienen que permitir al nuevo sistema ser operativo 21 . En este sentido, si el proyecto incluye la migración total o parcial del sistema, puede resultar eficiente enlazar esta fase con la de planificación de la migración. Normalmente, la dotación de recursos materiales se adjudica evaluando las características de las propuestas de los proveedores según un conjunto de ba- ses específico. Este conjunto de bases tiene que crearse a partir de los requeri- mientos del sistema, con el fin de poder garantizar la adecuación y la integra- ción con el resto del proyecto. La evaluación de las diferentes propuestas es particular en relación con el pro- yecto, el sistema y la organización. A grandes rasgos, se pueden valorar los siguientes aspectos: • Sistema￿e￿interoperabilidad: hay que valorar cada elemento en sí mismo, su adecuación e integración en el sistema, en el proyecto y en la organi- zación. • Funcionalidad￿y￿ergonomía: hay que valorar la facilidad de manipula- ción y configuración del elemento, así como de los conocimientos nece- sarios para la puesta a punto y su utilización cotidiana. (21) Como, por ejemplo, la instala- ción de una red de área local, la habilitación de un local técnico o la compra de conmutadores, orde- nadores y servidores. Ved también Consultad los apartados "Estra- tegias de migración", "Inven- tario de hardware y software" y "Diagrama de red y de es- tructura" con el fin de conocer más aspectos de la planifica- ción de la migración.
  • © FUOC • P08/M2104/00604 73 Implantación, proyectos y empresas de software libre • Eficiencia￿y￿rendimiento: hay que valorar el rendimiento funcional y operativo en relación a las necesidades del sistema. • Eficacia￿y￿fiabilidad: hay que valorar la fiabilidad y la consecución de los objetivos en relación a los requerimientos del sistema. • Implantación￿y￿migración: hay que valorar la facilidad para implantar el elemento en el entorno de la organización y las herramientas que incor- pora para migrar con respecto a la solución actual. • Mantenimiento,￿soporte￿y￿garantía: hay que valorar las necesidades para el funcionamiento y mantenimiento del elemento, así como el soporte y las garantías que ofrecen los proveedores. • Economía: hay que valorar la relación entre el coste del elemento y los resultados que ofrece, las ventajas e inconvenientes del impacto en el fun- cionamiento de la organización. Por otra parte, la implantación del proyecto también puede requerir la dota- ción de recursos humanos en la organización, ya sea para la manipulación di- recta o indirecta del sistema. Hay que destacar que el proyecto surge de una actuación estratégica de la organización y que, por lo tanto, es posible que el cambio de métodos y procedimientos implique una reestructuración del per- sonal implicado. En este sentido, el caso extremo correspondería a una organización de nueva creación, o a una organización ya creada pero que no disponga de ningún so- porte informático para su funcionamiento. La demanda de perfiles tecnológi- cos iría en consonancia con el grado de implantación tecnológica, la tipología del proyecto y las características de la organización. De todos modos, la selección de los recursos humanos tendría que integrarse en la metodología habitual de selección que utiliza la organización, pero habrá que destacar la necesidad de adecuar el perfil del candidato a los requisitos tecnológicos del sistema y de la nueva estrategia de la organización. 2.6.2. Configuración y/o desarrollo de software La fase de desarrollo de software pretende implementar todos los ajustes que requiere la solución en software libre con el fin de adecuarse al plan de proyec- to. También se puede incluir en esta etapa el desarrollo de herramientas que puedan ayudar a la conversión de datos o ficheros en la migración del sistema.
  • © FUOC • P08/M2104/00604 74 Implantación, proyectos y empresas de software libre El principal objetivo de esta fase es garantizar la idoneidad de la solución en software libre a los requisitos del proyecto, con el ajuste y codificación de todos los cambios que sean necesarios, aprovechando la apertura del código fuente y la libertad para ser modificado. La amplitud de esta fase dependerá directamente de los cambios que se tengan que introducir en la propuesta. Globalmente, se pueden distinguir tres casos diferentes: • Implantación￿directa. En el caso de la implantación directa de software, el escenario de desarrollo se limita al eventual ajuste de los ficheros de configuración o parámetros del software. Por ejemplo, la configuración del sistema operativo (idioma, acceso a la red, etc.) o parámetros de herramientas de ofimática (plantillas, idioma, etc.). Este caso supone una inversión temporal y económica ínfima con respecto a los otros dos casos. • Evolución￿del￿software. La evolución del software considera la amplia- ción o adecuación del código fuente de una o más soluciones de software libre, con el objetivo de ajustar su funcionamiento al de la organización. La importancia de los resultados incide en la necesidad de proceder con el rigor habitual de la ingeniería del software, estableciendo un ciclo de vida adecuado para cada modificación; eventualmente, de reingeniería del software. Por ejemplo, la introducción de cálculos adicionales en el software de ges- tión contable o la modificación del gestor de descargas de un navegador web. • Desarrollo￿nuevo. El caso del desarrollo de código nuevo considera que no existe ninguna solución adecuada a las necesidades específicas de la or- ganización. Sin embargo, puede resultar útil estudiar y reutilizar el código fuente de aplicaciones abiertas con el fin de ganar tiempo y fiabilidad. El desarrollo nuevo es el más laborioso en términos de coste temporal y económico. Estas implicaciones inciden en la necesidad de proceder se- gún metodologías de ingeniería del software adecuadas al proyecto. Por ejemplo, la creación de software de diseño industrial o arquitectónico o de control electrónico de dispositivos. En este sentido, cualquier proyecto de desarrollo de software se guiará por su ciclo de vida particular y establecerá los hitos de control y de calidad opor- tunos, evaluando el seguimiento y los resultados según la metodología más adecuada. Independientemente del formato de desarrollo, es aconsejable realizar en esta fase la documentación del proceso de adecuación del software, con la lista y descripción de todos los detalles que han estado sujetos a modificaciones, Ved también Podéis ampliar los conocimien- tos metodológicos para la pro- ducción de software libre en la asignatura de "Ingeniería del software en entornos de soft- ware libre".
  • © FUOC • P08/M2104/00604 75 Implantación, proyectos y empresas de software libre con el mismo rigor que en desarrollos nuevos. En estas circunstancias hay que tener presente la licencia final de la solución que se evoluciona, ya que normalmente la libertad del código fuente se hereda de la solución original. En esta fase también puede convenir desarrollar los materiales de formación de los usuarios del sistema, así como ajustar los manuales de soporte de las soluciones en software libre, ya que se dispone de todos los elementos nece- sarios para su realización. En estos casos, también hay que tener en cuenta las características de las licencias de los manuales que se pretende modificar. Manuales de soporte Las preguntas más frecuentes (PMF, en inglés FAQ, frequently asked questions) o los habi- tuales manuales de resolución de tareas concretas (how to en inglés), que a pesar de tener un marcado aspecto técnico, pueden ser de gran ayuda. 2.6.3. Evaluación final La fase de evaluación final de la etapa de desarrollo es el quinto punto de control del proyecto, y tiene el objetivo de garantizar que el desarrollo sigue los requisitos del plan de proyecto. También tiene el objetivo de reducir el riesgo global del proyecto, mediante la validación de la viabilidad y adecuación del desarrollo a la estrategia de la organización. Normalmente, la evaluación de esta etapa depende de la tipología del propio desarrollo: • Recursos,￿instalaciones￿e￿infraestructuras: se valoran según el cumpli- miento de los objetivos con respecto al diseño y la propuesta del provee- dor. Hay que señalar la importancia de los plazos de entrega y su repercu- sión en la planificación temporal de otras etapas. • Implantación￿directa￿de￿software: se valora el cumplimiento de los obje- tivos de los ajustes de configuración y la operativa prevista. La evaluación principal se considera sobre las pruebas de funcionamiento. • Evolución￿o￿desarrollo￿de￿software: la complejidad de la valoración es proporcional a la magnitud de los cambios introducidos. Normalmente, se considera la valoración que resulta del proceso de ingeniería del software. Esta fase tiene una estrecha relación con la implantación y la migración del sistema, ya que en función del tipo de proyecto, se pueden implantar las so- luciones a medida que finalice su desarrollo. Eventualmente, también puede tener relación con la formación de los usuarios y las pruebas piloto, ya que puede ser útil conocer las apreciaciones de los usuarios con el fin de perfeccio- nar algunos detalles del desarrollo 22 . (22) Como, por ejemplo, la interfaz gráfica, la respuesta del sistema o las características de los procedi- mientos que implementa el mis- mo.
  • © FUOC • P08/M2104/00604 76 Implantación, proyectos y empresas de software libre La importancia de este punto de control es doble: • Por una parte, porque revisa, evalúa y valora el desarrollo cualitativo de las soluciones y su adecuación a los requisitos estratégicos de la organización. • Por otra parte, porque supone la finalización del proceso de creación y adecuación de la solución y el inicio de la implantación e integración de- finitiva del sistema en la organización. En general, la fase de evaluación del desarrollo es un buen momento para in- troducir a los usuarios en las particularidades del sistema, y se podrá conside- rar la situación como inicio de la formación y adaptación de los usuarios al nuevo entorno. Estas actuaciones se pueden enmarcar dentro de la gestión del cambio que tiene que llevar a cabo la organización, con el objetivo de vencer las eventuales reticencias y miedos de los usuarios 23 . La evaluación final de la etapa de desarrollo puede acabar en tres grandes tipos de decisiones: • Sistema￿viable￿para￿ser￿implantado. La evaluación determina que el sis- tema cumple los requisitos de la organización y que se han desarrollado y se han integrado correctamente todas las modificaciones de la solución original. Se puede iniciar la implantación del sistema en la organización. • Sistema￿viable￿para￿ser￿implantado￿parcialmente. La evaluación deter- mina que el sistema cumple parcialmente los requisitos del proyecto en la fecha de control. Esta situación se debe normalmente a retrasos en la pro- ducción, que pueden ser consecuencia de imprevistos relacionados con la falta eventual de recursos materiales, el decalaje excesivo en su entrega o la falta de efectivos humanos para la producción. En cualquier caso, la viabilidad del proyecto no se ve afectada aunque ha- brá que asumir un retraso en la implantación. • Sistema￿inviable￿para￿ser￿implantado. Aunque no es habitual que el de- sarrollo de una solución resulte inviable, es posible que excepcionalmen- te pueda haber factores que afecten a la resolución y no se hayan podido solucionar durante la etapa. Este tipo de problemas se relacionan normal- mente con factores externos al proyecto, como por ejemplo cambios brus- cos en la estrategia o el agotamiento de la dotación económica. El aborto prematuro del proyecto en esta etapa tiene fuertes implicaciones económicas, funcionales y morales en la organización, y dificultará posi- bles actuaciones futuras. El resultado de esta etapa es doble: (23) En inglés, FUD (fear, uncertainty and doubt).
  • © FUOC • P08/M2104/00604 77 Implantación, proyectos y empresas de software libre • Por una parte, se obtiene el sistema que se quiere implantar, probado e integrado, con el objetivo de responder a los requisitos del proyecto y a las necesidades estratégicas de la organización. • Por otra parte, se obtiene la valoración de la viabilidad de la implantación y eventuales ajustes en la planificación temporal, como consecuencia de la evaluación de eventuales pruebas piloto. 2.7. Implantación y migración En este apartado se profundizará en los detalles técnicos de la implantación y la migración a sistemas basados en software libre. La mayoría de los proyectos de implantación son también proyectos de migración, ya que parten de un escenario en el cual hay un sistema in- formático basado en software propietario que se encuentra ya en pro- ducción. Los casos de implantación desde cero se dan en organizaciones de nueva creación que para la puesta en marcha de su primer sistema se orientan hacia una solución basada en software libre, o bien en organi- zaciones que hasta ahora no disponían de ningún sistema informático, lo cual pasa muy pocas veces. Con respecto a los problemas técnicos que el proyecto tiene que resolver, la implantación desde cero es siempre mucho más sencilla que la migración, principalmente porque no se encontrará ningún problema de compatibilidad hacia atrás. No obstante, hay que tener en cuenta que los usuarios del nuevo sistema normalmente estarán familiarizados con sistemas operativos y aplica- ciones de propiedad, por lo que la planificación de la formación es tan impor- tante como en un proyecto de migración. En este apartado siempre haremos referencia a proyectos de migración, porque son los que presentan una mayor dificultad y también porque los proyectos de implementación desde cero se pueden considerar como un subconjunto de los proyectos de migración, con la particularidad que en este caso se tiene más libertad para decidir el escenario final. Esta libertad presenta como con- trapartida la necesidad de prestar más atención a aspectos no funcionales del sistema, como dimensionarlo correctamente, por ejemplo. Así, se presentarán, en primer lugar, los diferentes tipos de proyectos de mi- gración y los aspectos más importantes de la planificación. En segundo lugar, se darán algunos consejos y orientaciones para ejecutar la migración y evaluar
  • © FUOC • P08/M2104/00604 78 Implantación, proyectos y empresas de software libre su resultado. Finalmente, se estudiarán en detalle todos los servicios implica- dos en el proyecto de migración, así como las soluciones basadas en software libre más populares para cada uno de ellos. 2.7.1. Tipos de migración Dentro de una organización se pueden llevar a cabo diferentes tipos de migra- ción a sistemas basados en software libre: según los objetivos, es decir, según cuáles sean los elementos del sistema que serán migrados, y según el alcance, es decir, según la cantidad de elementos que serán migrados. Según el objetivo: • Migración￿de￿servicios￿y￿servidores: afecta a los servidores de la organi- zación y a las aplicaciones o servicios que se ejecutan, por ejemplo, el ser- vicio de autentificación o el servicio de impresión, entre otros. En este caso las aplicaciones de los clientes no cambian, por lo cual sólo hay que pre- ver formación para los administradores de sistemas, y no para los usuarios finales. Son una de las migraciones más fáciles de llevar a cabo. En gene- ral, los servidores, funcionando con sistemas operativos GNU/Linux, de la familia BSD 24 u otros igualmente libres, suelen ser más fiables y ofrecen un rendimiento superior, lo cual aumentará la productividad de la orga- nización, tanto de los administradores de sistemas como de los usuarios finales (menos tiempo de respuesta del servidor). • Migración￿de￿usuarios￿y￿clientes: afecta a las máquinas cliente de los usuarios y a las aplicaciones que en ellas se ejecutan. En este caso se tiene que prever que será necesario formar y acompañar a los usuarios finales, que en general son menos receptivos a la utilización de nuevas aplicacio- nes y sufrirán más el cambio, con una posible pérdida de productividad temporal. • Migración￿de￿aplicaciones: afecta tan sólo a algunas de las aplicaciones que se ejecutan en los servidores o en las máquinas cliente, el sistema ope- rativo del cual no tiene por qué ser GNU/Linux u otro sistema operativo libre. De hecho, lo más habitual es que el sistema operativo continúe sien- do de propiedad. A veces es un paso previo a la migración del sistema ope- rativo. Son migraciones bastante sencillas de llevar a cabo, por ejemplo la migración a OpenOffice.org o a MySQL Community Server. Según el alcance: • Migración￿completa: resulta de la combinación de migrar tanto los ser- vidores como las máquinas cliente. La planificación de este tipo de migra- ción tiene que garantizar que los clientes no queden en ningún momento sin acceso a los servicios proporcionados por los servidores. Para ello, se (24) OpenBSD, FreeBSD o NetBSD. Ved también En el apartado "Diagrama de red y diagrama de estructura" se verán en detalle las particu- laridades de la migración de cada uno de estos servicios.
  • © FUOC • P08/M2104/00604 79 Implantación, proyectos y empresas de software libre suele realizar en primer lugar la migración total o parcial de los servidores y, a continuación, la migración de las máquinas cliente. • Migración￿parcial: resulta de la combinación de migrar tan sólo una par- te de los servidores o una parte de los clientes, de manera que continúa habiendo en el sistema máquinas basadas en software propietario. Un es- cenario habitual es aquél en el cual, en el mismo sistema, se encuentran clientes basados en software libre y clientes basados en software propieta- rio, cuya configuración dependerá de las necesidades o preferencias de los usuarios finales. • Migración￿basada￿en￿la￿virtualización: puede considerarse un tipo de migración parcial, en la cual se lleva a cabo la migración de servidores y máquinas clientes al mismo tiempo que se continúan instalando y ejecu- tando aplicaciones basadas en software propietario que no se ha podido incluir en la migración, ya sea por la ausencia de equivalentes en software libre o por otras razones. La virtualización permite iniciar un sistema ope- rativo de propiedad sobre un sistema operativo libre y utilizarlo a todos los efectos, ejecutando aplicaciones basadas en software propietario. Por otra parte, hay que tener en cuenta que, si bien el escenario típico de migración es aquél en el cual se pasa de un sistema operativo de propiedad a GNU/Linux, existen otras posibles combinaciones, como son: • De un sistema operativo de propiedad a un sistema operativo libre, por ejemplo los pertenecientes a la familia BSD. • De un sistema operativo libre a otro sistema operativo libre. El sistema operativo OpenBSD El sistema operativo OpenBSD destaca por la calidad de sus mecanismos de seguridad y la integración de la criptografía integrada, lo cual lo hace especialmente indicado para servidores u otro tipo de máquinas cuya integridad pueda verse comprometida. 2.7.2. Estrategias de migración Como en todo proyecto, una planificación correcta es una condición impres- cindible para asegurar el éxito de la migración a un sistema basado en softwa- re libre. Hay tantas planificaciones como proyectos, y todas serán más o me- nos válidas si se ajustan a los requisitos y las particularidades del escenario de migración planteado. Sin embargo, según la planificación de la migración, se pueden extrapolar cuatro grandes estrategias de migración: • Migración￿en￿un￿único￿paso: implica llevar a cabo todo el proceso de migración en un corto espacio de tiempo, si puede ser en un solo día, o en días de fiesta. Esta estrategia requiere identificar y definir todas las tareas que se tienen que realizar, ya que un error en una de ellas puede dejar sin servicio a todo el sistema, con el consiguiente riesgo de retrasos
  • © FUOC • P08/M2104/00604 80 Implantación, proyectos y empresas de software libre y rechazo por parte de los usuarios. Esta estrategia es la más económica y se suele aplicar en sistemas de dimensiones reducidas, con pocos clientes y un único servidor, por ejemplo en el caso de pequeñas empresas. • Migración￿piloto: implica llevar a cabo, en primer lugar, la migración de una pequeña parte del sistema, con la cual se practicará y evaluará el éxito de la migración, antes de proceder a la implantación en el resto del sistema. El sistema piloto consiste en unos cuantos servidores y máquinas cliente, incluso podría tratarse de un solo servidor y una sola máquina cliente. Si bien una planificación correcta es muy importante, esta estrategia permite una mayor flexibilidad para modificar el planteamiento de la migración y corregir posibles problemas. En contrapartida, esta estrategia requiere muchos más recursos y, por lo tanto, suele utilizarse en organizaciones con sistemas medianos o grandes. • Migración￿por￿grupos: implica definir grupos de usuarios según sus ca- racterísticas funcionales y llevar a cabo la migración gradualmente con ca- da uno de estos grupos. Una de las principales ventajas de esta estrategia es que permite minimizar los riesgos e ir aprendiendo en cada una de las migraciones. Además, sólo una parte del sistema se ve afectado por la mi- gración, lo cual permite suavizar la pérdida de productividad. Como con- trapartida, a menudo hay que mantener los sistemas anteriores en funcio- namiento, mientras se va desplegando el sistema basado en software libre. La migración por grupos normalmente es un buen momento para renovar el hardware, y viceversa. • Migración￿por￿usuarios: es similar a la migración por grupos, con la par- ticularidad que sólo se migra un usuario cada vez. En consecuencia, esta estrategia necesita muy pocos recursos pero es inviable en organizaciones grandes y medianas, en las cuales el elevado número de usuarios prolonga- ría durante demasiado tiempo la migración. No obstante, puede ser acon- sejable para llevar a cabo la migración de sistemas y usuarios críticos que necesiten un seguimiento especial. Estas estrategias no son exclusivas y dentro de un mismo proyecto se pueden aplicar varias. Por ejemplo, en una organización en la cual ciertos departamen- tos de tamaño más reducido o de menor importancia lleven a cabo una mi- gración en un único paso, y otros en los cuales se lleve a cabo una migración piloto antes de la implantación completa. De la misma manera, la migración por grupos se puede ver como una combinación de la migración en un solo paso y la migración piloto.
  • © FUOC • P08/M2104/00604 81 Implantación, proyectos y empresas de software libre 2.7.3. Inventario de hardware y software Para planificar la migración hace falta identificar el hardware y el software existente en la situación inicial, y de cuáles se espera disponer después de la migración. En consecuencia, se tiene que hacer un inventario detallado tanto del hardware como del software. El inventario de hardware tiene que incluir todas las máquinas disponibles para la migración, incluidas las máquinas retiradas, ya que algunas se pueden reutilizar. El hardware se puede clasificar en las categorías siguientes: • Hardware￿soportado￿sin￿problemas￿en￿GNU/Linux: se incluye hardware que desde el origen es soportado por el núcleo Linux o por controladores libres, así como hardware para el cual hay que utilizar controladores de propiedad, sea directamente o mediante adaptadores. La mayoría de hard- wares dispone de un buen soporte en GNU/Linux, por lo cual se clasifica en esta categoría. Más adelante se detallará cada una de estas situaciones. • Hardware￿soportado￿con￿algunas￿limitaciones￿en￿GNU/Linux: se in- cluye hardware que funciona únicamente en versiones antiguas del nú- cleo Linux, que no son las utilizadas en las distribuciones GNU/Linux más recientes, hardware que funciona con controladores muy antiguos para los cuales no existe mantenimiento y hardware cuyos controladores li- bres presentan limitaciones funcionales con respecto a los controladores de propiedad 25 . Distribución GNU/Linux La producción de una distribución GNU/Linux implica la verificación que todos los pa- quetes incluidos en la distribución son compatibles entre ellos y, especialmente, con la versión del núcleo. Por ello hay siempre un desfase de diversos meses entre la fecha de aparición de la distribución y la de su núcleo, más antiguo. (25) Como por ejemplo, adaptado- res gráficos con aceleración 3D cu- yos controladores libres sólo dispo- nen del modo 2D. • Hardware￿no￿soportado￿en￿GNU/Linux: se incluye el hardware que no funciona de ninguna manera en GNU/Linux. Realmente, hay muy poco hardware que no disponga de soporte en GNU/Linux y, cuándo eso pasa, se debe bien al hecho de que el hardware es muy nuevo y todavía no se han desarrollado los controladores apropiados, bien al hecho de que el hardware es muy antiguo y es incompatible con versiones más nuevas del núcleo Linux, bien al hecho de que el hardware es dependiente de un sistema operativo en concreto y, por lo tanto, inutilizable en GNU/Linux 26 . A su vez, el hardware soportado por GNU/Linux se puede clasificar según el tipo de soporte de la siguiente manera: (26) No obstante, en este caso, una solución basada en la virtualización podría ser posible.
  • © FUOC • P08/M2104/00604 82 Implantación, proyectos y empresas de software libre • Hardware￿ soportado￿ desde￿ el￿ origen￿ por￿ GNU/Linux: la mayoría de equipos y sus dispositivos disponen de un soporte adecuado en las distri- buciones GNU/Linux recientes, y por eso no hay que recurrir a controla- dores externos. Es fácil encontrar en Internet listas del hardware soporta- do por GNU/Linux. Página web Podéis informaros sobre hardware soportado por GNU/Linux en: http:// hardware4linux.info/. • Hardware￿soportado￿por￿controladores￿libres: una parte importante de los dispositivos, si bien no están soportados desde el origen por GNU/Li- nux, funcionan correctamente con controladores mantenidos por la co- munidad de software libre. A menudo, los gestores de paquetes incluidos con las distribuciones GNU/Linux proponen la instalación de estos con- troladores cuando detectan el hardware. • Hardware￿soportado￿por￿controladores￿propietarios: para este tipo de dispositivos no hay controladores mantenidos por la comunidad de soft- ware libre, y entonces hay que utilizar controladores propietarios a menu- do suministrados por el mismo fabricante. Suele tratarse de hardware con funcionalidades muy específicas, por ejemplo las aceleradoras gráficas. Sin embargo, poco a poco el soporte para este tipo de dispositivos va aumen- tando y a menudo los mismos fabricantes liberan sus controladores. • Hardware￿soportado￿mediante￿adaptadores: son aquéllos para los cua- les no hay soporte en GNU/Linux, pero sí para otros sistemas operativos de propiedad. Afortunadamente, hay herramientas denominadas adapta- dores que permiten utilizar controladores de estos sistemas operativos de propiedad bajo GNU/Linux. La clasificación correcta del hardware permitirá hacerse una idea precisa de los recursos disponibles, así como de la necesidad eventual de comprar nue- vos equipos. Por otra parte, como se ha comentado anteriormente, se puede destacar que los requisitos de hardware de los sistemas GNU/Linux son consi- derablemente menores que los de los sistemas operativos de propiedad, por lo cual máquinas obsoletas pueden reutilizarse con el fin de ofrecer servicios de impresión o de correo electrónico, entre otros. Una vez hecho el inventario de hardware, habrá que hacer un inventario de software. Eso implica identificar todas las aplicaciones que se utilizan en el sistema antes de la migración, basadas en software propietario, y las mejores aplicaciones basadas en software libre que puedan sustituirlas. Página web NDISwrapper es un proyecto de software libre que permi- te utilizar tarjetas de red ina- lámbricas bajo GNU/Linux mediante controladores Win- dows.
  • © FUOC • P08/M2104/00604 83 Implantación, proyectos y empresas de software libre En Internet hay muchas listas con las equivalencias entre aplicaciones de pro- piedad y libres. Sin embargo, a veces habrá que llevar a cabo un estudio deta- llado de las funcionalidades de cada aplicación para escoger al mejor candida- to entre las opciones basadas en software libre. Cuando se trata de aplicaciones de uso más común, como las ofimáticas, el número de opciones es elevado y a menudo hay una aplicación o un paquete de aplicaciones que destaca por encima de las otras. Para aplicaciones de usos más específicos a menudo hay comunidades de desarrolladores y usuarios, en las cuales puede ser interesante pedir consejo y a veces implicarse y todo. En caso de que no haya aplicaciones ni proyectos basados en software libre, la organización podría evaluar la posibilidad de desarrollar la aplicación en la medida de sus necesidades y liberarla bajo una licencia libre, siempre que disponga de bastantes recursos. Los beneficios son evidentes: la contribución potencial de desarrolladores y usuarios externos y el aumento de la visibilidad para la organización. 2.7.4. Diagrama de red y diagrama de estructura En este apartado se presentarán dos elementos esenciales en una migración de sistemas: el diagrama de red, que muestra la conectividad entre los diferentes elementos del sistema, y el diagrama de estructura, que indica su ubicación física. Página web El proyecto SourcePYME ofrece una lista de aplicacio- nes y servicios bastante ex- tensa y actualizada (http:/ /www.sourcepyme.org/ ?q=node/13). Hay igualmen- te un gran número de recur- sos en inglés. Ved también En el apartado "Evaluación de la migración" se presentarán las alternativas existentes pa- ra la migración de los servicios esenciales de una organiza- ción. De esta manera, una vez se conoce el hardware y el software que se verá afec- tado por la migración, se pasará a representar el sistema mediante un diagrama de red. El diagrama de red tiene que contener los elementos siguientes: • Servidores. Se indicará el nombre del equipo, junto con los principales servicios ofrecidos por cada servidor. • Equipos￿cliente￿o￿de￿usuario. Se indicará el nombre del equipo, así como los dispositivos de red que estén expuestos al resto del sistemas. • Impresoras. Se indicará el nombre de la impresora y de qué servidor de impresión o de qué equipo cliente dependen. • Otros￿equipos￿de￿red. Se indicarán los principales equipos que formen la red del sistema y permitan la conectividad entre los diferentes equipos. Por ejemplo concentradores o hubs, encaminadores o routers, conmutadores o switches y puntos de acceso inalámbrico o access points. • Conectividad￿entre￿los￿elementos. Se indicarán las conexiones de red por cable e inalámbricas entre los diferentes elementos del sistema. Se indicará igualmente la salida a redes externas desde la red local de la organización Página web Una excelente aplicación de software libre para realizar diagramas de red, entre otros tipos de diagramas, es Dia (http://live.gnome.org/Dia).
  • © FUOC • P08/M2104/00604 84 Implantación, proyectos y empresas de software libre como Internet, redes privadas virtuales (VPN) y organizaciones virtuales (VO). En el diagrama de red es muy importante que cada equipo esté identificado de manera unívoca. En primer lugar, se hará un diagrama de red que recoja el estado del sistema antes de la migración. A partir de este diagrama se estudiarán cuáles son las posibilidades de optimización de la red actual, como resolver cuellos de botella en los servidores o conectar ciertas impresoras locales en un servidor central de impresión. De la misma manera, se decidirá qué equipos nuevos y qué ele- mentos de red se introducirán en el sistema como nuevos servidores, equipos antiguos que puedan funcionar con GNU/Linux o el despliegue de una red inalámbrica. Con estos elementos se construirá el diagrama de red del sistema posterior a la migración. Este diagrama será esencial para definir la planificación y la estrategia de la migración, y mientras dure la implantación servirá siempre de guía. Por eso convendrá mantener el diagrama de red siempre al día, de manera que refleje fielmente el estado del sistema. Como se ha comentado al principio del apartado, el diagrama de estructura refleja la ubicación física de los equipos dentro de la organización o, dicho de otra manera, nos indica qué equipos hay en cada sala. De la misma manera que se ha hecho con el diagrama de red, se diseñará un diagrama de estructura que represente el estado del sistema antes de la migración a partir del cual se podrá decidir la ubicación de los equipos después de hacer la migración. Una de las consecuencias más frecuentes de la migración es la puesta en mar- cha de servidores dedicados a un reducido número de servicios, a veces incluso en exclusiva. Por ello los servidores suelen agruparse en la misma ubicación física (típicamente una sala de servidores), que presentará requisitos particu- lares de climatización, suministro de energía y accesibilidad, entre otros. Otro ejemplo es la conexión de impresoras (hasta ese momento locales) en un ser- vidor de impresión, que se pueden ubicar en la misma sala. Si bien en organizaciones reducidas, con un entorno de una decena de equi- pos, el diagrama de estructura no es especialmente importante, en escenarios de migración extensos resulta imprescindible para ubicar cada uno de los equi- pos y elementos de red.
  • © FUOC • P08/M2104/00604 85 Implantación, proyectos y empresas de software libre 2.7.5. Ejecución de la migración En la ejecución de toda migración, e independientemente de la estrate- gia de migración que se haya adoptado, hay una serie de tareas técnicas que casi siempre se repiten: instalación de equipos, migración de datos, realización de copias de seguridad, emulación de aplicaciones. Junto con estas tareas técnicas, destaca la importancia de disponer de un plan de gestión de los riesgos que pueden presentarse en la migración. En este apartado veremos brevemente cada una de estas tareas y daremos al- gunas orientaciones para llevarlas a cabo: •￿ Instalación￿ de￿ equipos. Hay herramientas de instalación automática de equipos con el fin de poder instalar y configurar fácilmente muchos en un tiempo reducido. Una de estas herramientas es SystemImager, que permite automatizar la ins- talación de imágenes o clones del sistema GNU/Linux instalado en un primer equipo. SystemImager permite también distribuir nuevas aplicaciones o datos en los equipos del sistema y realizar cambios en la configuración o instalar actualizaciones del sistema en redes con equipos GNU/Linux. Sin embargo, en caso de que el hardware de los equipos no sea idéntico, puede ser que haya que configurarlos manualmente. •￿Migración￿de￿datos￿de￿usuario. Los nombres y direcciones de los usuarios suelen almacenarse en servicios de directorio, normalmente accesibles a través del protocolo estándar LDAP, que facilita la migración de estos datos a nivel del sistema. Sin embargo, al nivel de las aplicaciones que hacen uso de estos datos, como clientes de correo o aplicaciones para trabajo en grupo, se suelen utilizar es- quemas de datos diferentes para estructurar la información. En consecuencia, los datos son pocas veces interoperables entre ellos y entonces hay que utilizar programas externos que sincronicen los datos entre aplicaciones. •￿Realización￿de￿copias￿de￿seguridad. En general, las copias de seguridad hacen referencia a la copia de datos de manera que estas copias adicionales permitan restaurar un sistema después de una pérdida de información. La im- plantación de sistemas GNU/Linux comporta a menudo el formateo y parti- ción de los equipos implicados en la migración, por lo cual habrá que realizar copias de seguridad de los datos existentes, con el fin de restaurarlas después en el nuevo sistema. Pàgina web Podéis encontrar más información sobre Sys- temImager en http:// wiki.systemimager.org/. SystemImager SystemImager permite guardar la imagen de un sistema GNU/ Linux en producción antes de realizar cambios en el sistema, lo que garantiza poder volver a la situación original. Ved también Podéis consultar el apartado "Inventario de hardware y soft- ware" para obtener más deta- lles sobre la migración de ser- vicios de directorio.
  • © FUOC • P08/M2104/00604 86 Implantación, proyectos y empresas de software libre Si la organización dispone de un mecanismo de copia de seguridad actuali- zado, una buena opción es utilizarlo para recuperar toda la información que tenga que ser copiada en los nuevos equipos. Si la organización no dispone de ningún mecanismo de copia de seguridad, se puede poner en marcha un servicio de almacenamiento exclusivamente para almacenar los datos que tienen que migrar. Otra opción es desplegar en primer lugar el servicio de almacenamiento previsto en el plan de proyecto y propor- cionar acceso a los usuarios del sistema de manera que puedan almacenar sus datos antes de migrar los equipos de usuario. En cualquiera de estos dos casos, la participación de los usuarios es fundamental. Por otra parte, una vez concluida la migración hará falta poner en marcha un mecanismo de copias de seguridad incremental 27 . Como regla general, el sistema original y la copia tienen que ser cuanto más independientes mejor, de manera que un error en uno no afecte al otro. •￿Emulación￿de￿aplicaciones￿y￿virtualización. La realización del inventario de software servirá para saber qué aplicaciones no se pueden ejecutar de mane- ra nativa en GNU/Linux y tampoco pueden ser sustituidas por una aplicación libre equivalente. En caso de que estas aplicaciones sean imprescindibles, hay dos posibles soluciones con el fin de poder continuar utilizándolas: la emula- ción y la virtualización. Wine, la solución libre más popular Wine es la solución libre más popular para ejecutar aplicaciones nativas de Windows en un sistema GNU/Linux. Aunque se suele decir que Wine (http://www.winehq.org/) es un emulador, es más correcto afirmar que Wine proporciona una capa de compatibilidad para aplicaciones Windows. De hecho, Wine corresponde a las siglas de Wine is not an emulator (Wine no es un emulador). Wine no necesita instalar ninguna partición Windows, aunque en algunos casos puede convenir disponer de algunas bibliotecas nativas de Windows. Las aplicaciones ejecuta- das con Wine pueden acceder al sistema de archivos, la red y los servicios de impresión de manera completamente transparente. En el sitio web de Wine pueden consultarse qué aplicaciones están soportadas y con qué nivel de funcionalidad. Para aplicaciones que no se ejecuten correctamente con Wine hay la posibilidad de eje- cutarlas en un sistema operativo virtualizado. Como se ha introducido anteriormente, la virtualización permite ejecutar un sistema operativo encima de otro. En este caso se trataría de ejecutar la aplicación en un sistema Windows virtual sobre un sistema GNU/ Linux. Las soluciones libres más populares de virtualización son QEMU, Xen i KVM. En cualquier caso, la virtualización siempre se tiene que considerar en último lugar, ya que implica continuar utilizando y pagando licencias de propiedad y supone un gran consu- mo de recursos del sistema. (27) Hay múltiples soluciones dis- ponibles, entre las cuales destaca RSync (http://samba.anu.edu.au/ rsync) y Amanda (http:// amanda.org). •￿Gestión￿de￿riesgos. La migración a un sistema basado en software libre es un proceso que no está exento de riesgos, por lo cual es importante preparar un plan de gestión y mantenerlo durante toda la ejecución del proyecto. Ved también Podéis consultar el apartado "Gestión de riesgos" para obte- ner más detalles sobre la reali- zación de planes de gestión de riesgos.
  • © FUOC • P08/M2104/00604 87 Implantación, proyectos y empresas de software libre Los riesgos y su importancia relativa dependerán del escenario de migración y de las particularidades de la organización. Por ejemplo, para ciertas organiza- ciones puede ser una prioridad garantizar la seguridad e integridad de ciertos datos confidenciales, por lo cual se tendrá que prevenir esta contingencia y definir un plan para solucionarla en caso de que finalmente ocurra. Como regla general, se sugiere que el proceso de migración sea reversible hasta que no se haya verificado completamente el nuevo sistema, es decir, que se pueda volver a la situación de partida en el caso improbable de que la migra- ción falle o acabe siendo inviable. 2.7.6. Evaluación de la migración En todo proyecto de migración es esencial llevar a cabo una evaluación tanto del sistema final como del proceso de migración. Esta evaluación puede hacerse una vez concluida la migración, pero también durante la misma, en caso de que ésta no se realice en un único paso. El plan de proyecto tiene que incluir, por lo tanto, una serie de indicadores bien definidos. Algunos de estos indicadores pueden ser los siguientes, según hagan referencia al sistema operativo, a los servidores, a las aplicaciones o a los usuarios: • Indicadores￿del￿sistema. ¿Se ha aumentado la fiabilidad, el rendimiento y la seguridad del sistema después de la migración? ¿Cómo ha variado el coste real (no estimado) de mantenimiento del sistema? ¿Se han desplega- do nuevos servicios en el sistema? ¿Cuál es la valoración de los adminis- tradores del nuevo sistema? ¿Ha disminuido el número de incidencias de los diferentes servicios del sistema después de la migración? • Indicadores￿del￿sistema￿operativo. ¿Cuántos equipos han sido migrados al nuevo sistema? ¿Funcionan correctamente todos los equipos? ¿Todo el hardware está soportado en el nuevo sistema? ¿Cuántas veces ha habido que recurrir a soluciones basadas en la virtualización? • Indicadores￿de￿las￿aplicaciones. ¿Para cuántas de las aplicaciones exis- tentes se ha encontrado y ha sido implantada una aplicación equivalente en software libre? ¿Qué funcionalidades se han ganado o se han perdido con respecto a las aplicaciones originales? ¿Cuántas aplicaciones funcio- nan bajo emulación o virtualización? ¿Cuántas aplicaciones ha sido nece- sario modificar? ¿Cuántas aplicaciones se han tenido que desarrollar des- de cero? • Indicadores￿de￿los￿usuarios. ¿Cuántos usuarios han sido migrados al nue- vo sistema? ¿Cuál es su valoración de los aspectos funcionales y no fun-
  • © FUOC • P08/M2104/00604 88 Implantación, proyectos y empresas de software libre cionales del nuevo sistema y de las nuevas aplicaciones? ¿Cuál ha sido la variación de su productividad a corto y largo plazo? ¿Ha disminuido el número de incidencias de usuario al instalar el nuevo sistema operativo? 2.7.7. Migración de los servicios de un sistema En la mayoría de las organizaciones hay una serie de servicios esenciales, a los cuales se tiene que prestar especial atención a la hora de planificar y ejecutar la migración: • Sistema de archivos • Servicio de impresión • Servicio de directorio y autentificación • Servicio de red • Gestión y administración del sistema • Servidores web • Bases de datos • Entornos de escritorio y aplicaciones ofimáticas • Aplicaciones corporativas En este apartado, se presentarán las características principales de estos servi- cios y se mostrarán las soluciones basadas en software libre más populares. En general, siempre hay más de una alternativa, por lo que la elección final dependerá de las características y requisitos de cada escenario. Aclaración Si bien la mayoría de las soluciones basadas en software libre que se presentan en este apartado se encuentran en un estado maduro de desarrollo y se utilizan en muchos es- cenarios, la tecnología evoluciona continuamente, por lo cual es aconsejable visitar los sitios web de cada uno de los proyectos para obtener la información técnica más reciente e investigar otras soluciones que pudieran mejorar las existentes. Igualmente, la importancia de cada uno de estos servicios será diferente en función de las características de la organización. Es posible que algunos de estos servicios no se encuentren presentes en la situación inicial y, por lo tanto, no se incluyan en la migración. Sin embargo, la migración representa una excelente oportunidad para analizar y revisar el estado actual del sistema y diseñar una arquitectura que responda tanto a las necesidades actuales de la organización como a aquéllas necesarias a largo plazo. Por ello se tiene que considerar la inclusión de nuevos servicios no presentes en el sistema original.
  • © FUOC • P08/M2104/00604 89 Implantación, proyectos y empresas de software libre Sistema de archivos En la migración del sistema de archivos pueden darse dos situaciones, según si migran todos los clientes o tan sólo una parte: •￿Migración￿del￿servidor￿del￿sistema￿de￿almacenamiento￿pero￿no￿de￿los clientes En este caso, la opción más popular es el uso de Samba. Samba es una imple- mentación libre del protocolo utilizada en sistemas de archivos compartidos de Microsoft Windows para sistemas Unix que permite que ordenadores con GNU/Linux actúen como servidores o clientes en redes Windows. •￿Migración￿del￿servidor￿del￿sistema￿de￿almacenamiento￿y￿de￿los￿clientes En este caso, habitualmente se tiene en cuenta el uso de NFS o de OpenAFS. NFS permite acceder a archivos remotos dentro de una misma red como si se tratara de archivos locales. NFS viene incluido por defecto en el sistema operativo GNU/Linux. De forma similar, OpenAFS 28 es un sistema de archivos distribuido, utilizado generalmente en centros de servidores (clusters) y en escenarios de computación distribuida. La elección entre el uno y el otro (o la elección de otro sistema) dependerá de los requisitos de la migración. Es posible utilizar NFS o OpenAFS en redes que incluyan clientes Windows y GNU/Linux. Para la migración de los servidores que funcionan con GNU/Linux, hay múl- tiples sistemas de archivos, pero los más conocidos son Ext3 y XFS. Sus fun- cionalidades incluyen journaling, asignación de cuotas y privilegios de acceso basados en ACL (Access Control List) por archivo y directorio. Un aspecto a tener en cuenta en la migración del sistema de archivos es el mapeo de las ACL Windows a las ACL Posix, en el cual se puede perder cier- ta granularidad. En la práctica eso no suele pasar, ya que habitualmente las organizaciones hacen un uso completo de la granularidad permitida por las ACL Windows. Servicio de impresión La impresión es una de las fuentes de problemas más recurrentes en todas las organizaciones, en general a causa de la instalación de impresoras sin ninguna planificación, cosa que comporta numerosas incidencias técnicas y, a menudo, el despilfarro de recursos (papel, tinta, electricidad). De hecho, la migración a un sistema basado en software libre se presenta como una buena oportunidad para optimizar el servicio de impresión. (28) OpenAFS es una implementa- ción libre de un sistema de archi- vos originariamente desarrollado por la Universidad Carnegie Me- llon, que influyó también en el di- seño de NFS.
  • © FUOC • P08/M2104/00604 90 Implantación, proyectos y empresas de software libre Entre las soluciones basadas en software libre, CUPS es el servidor de impre- sión utilizado por la mayoría de distribuciones GNU/Linux y es de hecho la mejor opción en casi todos los escenarios de migración. Una de sus principales ventajas es que permite disponer de un servicio de impresión tanto para clien- tes GNU/Linux como para clientes Windows, gracias a la implementación del protocolo de impresión por Internet (Internet Printing Protocol, IPP). El protocolo IPP es un estándar de impresión tanto en redes LAN como WAN y soporta la comunicación entre cliente y servidor, entre diferentes servidores y entre servidor y la impresora seleccionada. Todas las impresoras modernas lo soportan. Hay que tener en cuenta que antes de llevar a cabo la migración se tienen que comprobar el soporte y los controladores existentes para cada impresora. Servicio de directorio y autentificación Un servicio de directorio tiene como finalidad que una determinada informa- ción esté disponible para todos los usuarios de una red. Esta información nor- malmente está compuesta por objetos que se organizan de una manera jerár- quica, con su origen en un objeto raíz. El protocolo que se utiliza más a me- nudo para acceder es el LDAP. LDAP (Lightweight Directory Access Protocol) Inicialmente, el LDAP hacía referencia sólo al protocolo de acceso. Sin embargo, hoy en día se entiende por LDAP la combinación de la base de datos que contiene la información y el protocolo para acceder a ella. Por ejemplo, un uso bastante frecuente de un servicio de directorio es almace- nar las cuentas de los usuarios del sistema junto con sus privilegios, de manera que todas las aplicaciones y servicios del sistema pueden acceder a él con el fin de obtener este tipo de información, que dada su naturaleza es aconsejable que sea íntegra. Así, un servicio de directorio tiene que ofrecer las siguientes funcionalidades: • Tiene que modificar la información disponible y organizarla según una estructura jerárquica. • Tiene que usar un esquema de datos estándar, que asegure la compatibili- dad y la interoperabilidad con el mayor número de aplicaciones. • Tiene que autentificar usuarios y garantizar la interoperabilidad con otros servicios de autentificación. • Tiene que administrar los derechos de acceso a la información contenida en el servicio de directorio. • Tiene que garantizar la seguridad en la transmisión de la información entre los clientes y el servicio de directorio.
  • © FUOC • P08/M2104/00604 91 Implantación, proyectos y empresas de software libre Con el fin de llevar a cabo la autentificación junto con un servicio de direc- torio, la solución basada en software libre más frecuente es la combinación de OpenLDAP con Samba, en la cual éste último sirve como base de datos de las cuentas de usuario, mientras que OpenLDAP actúa como servicio de direc- torio. Un gran número de aplicaciones son compatibles con LDAP, como el paquete ofimático OpenOffice.org. El sistema GNU/Linux ofrece diversas herramientas LDAP 29 que permiten mo- dificar la información almacenada en el servicio de directorio, y hay también diferentes interfaces gráficas basadas en Web para la administración de usua- rios y grupos. Un servicio de directorio y autentificación basado en OpenLDAP y Samba per- mite además el uso de clientes Windows y Linux simultáneamente. De hecho, OpenLDAP actúa al mismo tiempo como parte del servicio de autentificación y como herramienta de integración en escenarios mixtos con clientes GNU/ Linux y Windows. En caso de que la migración a GNU/Linux sea completa, es posible también llevar a cabo la autentificación mediante Kerberos. Kerberos es un protocolo de autentificación que permite que dos ordenadores demues- tren mutuamente su identidad de una manera segura. Servicios de red (29) Por ejemplo, ldapsearch, lda- pad y ldapmodify. Toda la infraestructura de redes TCP/IP (DNS, DHCP, NTP, conexión de enca- minadores, filtraje, VPN) puede implementarse fácilmente mediante solucio- nes basadas en software libre, lo cual se debe principalmente al hecho de que todos los protocolos de Internet son estándares abiertos, tanto en su defini- ción como en sus implementaciones. Un aspecto a considerar en la migración de los servicios de red es la utilización de estándares abiertos, incluso en el caso en que no se tengan que utilizar (por ejemplo, en el caso de una pequeña red local), y así evitar el uso de modifica- ciones específicas de los fabricantes de hardware, que a la larga podrían provo- car problemas de incompatibilidad con otros sistemas a la hora de implantar nuevos servicios, e incluso una dependencia del fabricante. Entre los servicios de red destacan los siguientes: •￿DNS￿(sistema￿de￿nombres￿de￿dominio￿o￿domain￿name￿system) Nota Podéis consultar más informa- ción de los estándares abiertos en el anexo II de este módulo didáctico. La implementación de referencia en software libre es BIND (Berkeley Internet Name Domain), mantenida en la actualidad por la Internet Systems Consor- tium (ISC). BIND es el servidor de DNS más utilizado en Internet. La última versión es BIND 9, que incorpora DNSSEC (DNS Security Extensions), TSIG (Transaction Signature), notificación DNS, nsupdate y Ipv6 entre otras funcio- nalidades. Está disponible en todos los sistemas GNU/Linux. Internet Systems Consortium Internet Systems Consortium es una organización sin ánimo de lucro y el sucesor del Inter- net Software Consortium, tam- bién denominado ISC.
  • © FUOC • P08/M2104/00604 92 Implantación, proyectos y empresas de software libre •￿DHCP￿(protocolo￿dinámico￿de￿configuración￿de￿huésped￿o￿dynamic￿host configuration￿protocol) La implementación de referencia en software libre es dhcpd, también mante- nida en la actualidad por el ISC. dhcpd permite administrar clientes individua- les y configuraciones colectivas para clases y subredes. Además, dhcpd ofrece funcionalidades de balance de carga y alta disponibilidad. Está disponible en todos los sistemas GNU/Linux. •￿NTP￿(protocolo￿de￿tiempo￿de￿red￿o￿network￿time￿protocol) NTP es un protocolo de Internet que permite sincronizar los relojes de los sis- temas informáticos a través de el encaminamiento de paquetes, para evitar los problemas derivados de latencia variable en las redes. El NTP Project propor- ciona soporte para NTP y ofrece una implementación de referencia, disponible en todos los sistemas GNU/Linux. •￿WINS￿(Windows￿Internet￿name￿service) WINS permite resolver los nombres de los diferentes servicios y sistemas Win- dows. Esta función se puede sustituir por nmbd, incluido en el paquete Samba. Gestión y administración del sistema La mayoría de aplicaciones de control y de gestión de sistemas no son nativas en el sistema operativo y los fabricantes a menudo proporcionan versiones de estas aplicaciones para diferentes sistemas operativos. Esta situación presenta el inconveniente de que si bien hay un buen número de aplicaciones de ges- tión de sistemas para GNU/Linux, no están basadas en software libre. En cualquier caso, la gestión y el control de sistemas basados en software li- bre es muy diferente de la de sistemas basados en software propietario, como Windows. Los administradores de sistemas basados en software libre normal- mente no utilizan una única herramienta de gestión, sino un conjunto, cada una de las cuales especializada en una parte del sistema. De esta manera, los administradores tienen mucha más libertad para realizar ajustes y corregir los posibles problemas de sus sistemas, lo cual es una de las causas de la conocida fiabilidad y seguridad asociadas al software libre. Una primera opción para la automatización de tareas de administración en GNU/Linux es la utilización de cron y at. El primero (cron) es un adminis- trador de procesos en segundo plano que ejecuta programas a intervalos regu- lares. De una manera similar, la orden at permite la ejecución de programas en un momento determinado.
  • © FUOC • P08/M2104/00604 93 Implantación, proyectos y empresas de software libre Por otra parte, todo sistema GNU/Linux ofrece la funcionalidad básica de ad- ministración a través de una terminal remota ssh en otro cliente o servidor, exactamente de la misma manera que si se tratara de su máquina local, inclu- so a través de la interfaz gráfica del escritorio. El uso combinado de ssh con cron y at permite al administrador realizar una buena parte de las tareas de mantenimiento. Además, otras utilidades del sistema como strace, lsof o netstat ofrecen diferentes funcionalidades para detectar y analizar errores y pueden resultar útiles en la gestión de servidores. •￿Gestión￿de￿red Entre las soluciones disponibles para la gestión de redes TCP/IP como software libre se puede destacar Nagios y openNMS. Nagios permite monitorizar servidores y servicios para detectar problemas de red en sistemas basados en GNU/Linux. Un proceso en segundo plano contro- la los servidores y servicios especificados y envía la información al servidor de Nagios, que a su vez notifica al administrador del sistema en caso de que se detecte algún problema. Mediante una serie de plugins, Nagios permite moni- torizar de manera activa y pasiva servicios de red típicos como servidores de Web y de correo, pero también otros, como sistemas gestores de bases de datos. Por su parte, openNMS es una aplicación de gestión de redes que cumple el modelo FCAPS y permite determinar la disponibilidad de los diferentes servi- cios, almacenar la información y generar informes y notificar acontecimien- tos. No obstante, hay que tener en cuenta que la gestión de sistemas y redes de más complejidad puede requerir utilizar herramientas que no están disponi- bles como software libre. •￿Gestión￿de￿software La gestión de software implica la instalación y restauración de clientes, las dis- tribuciones de aplicaciones estándar y específicas y la gestión de actualizacio- nes y parches en todo el sistema. Entre las soluciones disponibles como software libre se puede destacar m23, un paquete de software para sistemas basados en la distribución Debian, que permite la instalación inicial de los clientes, incluyendo la definición de par- ticiones y la detección de hardware, la distribución y actualización de software y la restauración de clientes.
  • © FUOC • P08/M2104/00604 94 Implantación, proyectos y empresas de software libre Servidor web Apache es la principal alternativa para migrar e implantar el servidor web de una organización. Apache está presente en más del 60% de los servidores web y se distribuye libremente bajo la licencia Apache. Sus funcionalidades y rendimiento son excelentes y están sobradamente con- trastados en todo tipo de escenarios de producción. La arquitectura de Apache es modular y consiste en un núcleo que contiene las funcionalidad básicas del servicio y un gran número de módulos fácilmente instalables para aplicacio- nes específicas, como para soportar determinados lenguajes de programación como PHP, Java, Perl, etc. El proyecto Apache Apache es uno de los proyec- tos desarrollados por la co- munidad de software libre de más éxito, y a causa de ciertas particularidades de su licencia puede ser utilizado en produc- tos de software propietario. La migración de proyectos web 30 en un servidor web basado en Apache exige el estudio de las particularidades de cada proyecto, que a veces pueden dar lugar a incompatibilidades. Apache soporta perfectamente tanto contenidos estáticos (desarrollados en HTML) como dinámicos (desarrollados en lenguajes como PHP o Perl). Normalmente, las modificaciones que se tienen que aplicar en estos proyectos para asegurar su compatibilidad bajo Apache serán mínimas o nulas. Un caso especial son los proyectos desarrollados en tecnologías de propiedad como ASP, que requieren un esfuerzo importante para que funcionen bajo Apache. Siempre que sea posible, es preferible implementar de nuevo el pro- yecto web en tecnologías alternativas como PHP, de manera que se asegure la independencia tecnológica en el futuro. Eso supone sin duda un esfuerzo mayor, que en cambio se puede aprovechar para optimizar los contenidos y aplicaciones web de la organización. De hecho, la utilización de PHP como lenguaje de programación para la Web es cada vez más frecuente y en los últimos años se han generalizado las plata- formas LAMP (Linux, Apache, MySQL y PHP) con el fin de ofrecer contenidos y aplicaciones web. Bases de datos Hay muchas alternativas en software libre para la implantación de sistemas gestores de bases de datos, pero las más conocidas son MySQL, PostgreSQL, Firebird y MaxDB. La elección de una solución u otra dependerá del análisis de los requisitos de la migración. En cualquier caso, las bases de datos libres son productos maduros que han sido probados en entornos de producción y, de hecho, se pueden considerar como una de las puntas de lanza del software libre y del sistema GNU/Linux (30) Por proyecto web se entiende tanto una página web (por ejem- plo, la página web de la organiza- ción) como las aplicaciones basa- das en web y accesibles a través de un navegador.
  • © FUOC • P08/M2104/00604 95 Implantación, proyectos y empresas de software libre en los entornos empresariales. Hay que destacar también que estas soluciones cuentan con versiones para sistemas operativos de propiedad, por lo cual po- drían utilizarse en una migración únicamente de aplicaciones. Algunas bases de datos de propiedad como Oracle 31 disponen también de una versión para GNU/Linux, por lo que en los casos concretos en los cuales no fuere aconsejable migrar el sistema gestor de base de datos, sí que sería posible realizar la migración del sistema operativo en GNU/Linux. La mayoría de bases de datos ofrecen mecanismos más o menos estándar para su administración y consulta, lo cual en principio favorece la interoperabilidad y la utilización de otras soluciones, así como una migración fácil de los datos de un sistema gestor a otro, de manera que las aplicaciones puedan continuar accediendo a los datos de manera transparente y sin necesidad de ninguna modificación adicional. De esta manera, la migración de bases de datos implica llevar a cabo dos ope- raciones: • Migración￿de￿datos￿a￿la￿nueva￿base￿de￿datos. Esta operación requerirá más o menos esfuerzo según el estado inicial de los datos. En caso de que los datos sean accesibles mediante consultas SQL, una operación de expor- tación o trasvase de datos y la posterior importación a la nueva base de datos tendría que ser suficiente. En caso de que los datos se encuentren almacenados en algún formato de propiedad o incluso en ficheros de tex- to, hará falta implementar un analizador sintáctico (parser) e importarlos después a la nueva base de datos. • Verificación￿del￿acceso￿a￿datos￿desde￿las￿aplicaciones. En caso de que las aplicaciones utilicen un mecanismo estándar para leer los datos, por ejemplo consultas SQL, el acceso se tendría que realizar de la misma ma- nera, excepto si se utilizan comandos que no satisfacen el estándar. En caso de que las aplicaciones utilicen controladores estándar como ODBC o JDBC, o una interfaz propietaria, será necesario sustituir el controlador de la base de datos original por el de la nueva base de datos, o bien imple- mentar una interfaz nueva. En ambos casos, este paso puede suponer un esfuerzo considerable y dar lugar a problemas de interoperabilidad. Como regla general, y con el fin de facilitar la migración de bases de datos, se debe evitar como sea la utilización de procedimientos de consulta predefini- dos y extensiones específicas de los fabricantes en el acceso a los datos desde las aplicaciones. Por contra, es recomendable utilizar controladores estándar como ODBC o JDBC, fácilmente intercambiables, e implementar las consultas SQL de la manera más modular y aislada con respecto al resto del programa. (31) Oracle suele utilizarse en en- tornos bastante complejos que presentan una serie de requisitos que a veces las soluciones libres no ofrecen.
  • © FUOC • P08/M2104/00604 96 Implantación, proyectos y empresas de software libre Entornos de escritorio y aplicaciones ofimáticas En los sistemas GNU/Linux hay dos grandes alternativas de entornos de escri- torio: GNOME y KDE. Tanto GNOME como KDE proporcionan un entorno de escritorio intuitivo que incluye un gestor de ventanas fácil de utilizar para cualquier tipo de usuario y una plataforma de desarrollo que permite construir aplicaciones integradas con el resto del escritorio y entre ellas. La elección entre uno u otro depende en gran manera de los gustos personales. En general, KDE ofrece una interfaz más similar a la de Windows y más posi- bilidades de personalización, que sin embargo pueden suponer una dificultad adicional para los nuevos usuarios. Por otra parte, si bien hay un gran número de aplicaciones ofimáticas para los sistemas GNU/Linux que se integran bien con los sistemas de escritorio Gno- me y KDE, hay dos soluciones que destacan de entre las otras: OpenOffice.org y StarOffice. OpenOffice.org es un paquete ofimático de software libre y código abierto de distribución libre. Está disponible para múltiples plataformas tanto libres co- mo de propiedad, por lo cual se encuentra a menudo como ejemplo de migra- ción de aplicación. En la mayoría de los casos es compatible con Microsoft Office y soporta el estándar ISO OpenDocument para el intercambio de datos, que puede ser utilizado libremente. De hecho, OpenOffice.org está basado en el proyecto StarOffice. StarOffice es el paquete ofimático de propiedad y de pago de Sun Microsystems y contiene algunas funcionalidades adicionales 32 con respecto a OpenOffice.org, a la cual Sun Microsystems continúa dando su apoyo. Tanto OpenOffice.org como StarOffice incluyen diferentes aplicaciones, cada una de las cuales con unas funciones concretas, pero que se integran perfec- tamente las unas con las otras: • Procesador de textos (Writer) • Hoja de cálculo (Calc) • Presentación (Impress) • Editor de fórmulas matemáticas (Math) • Dibujo (Draw) • Base de datos (Database) (32) Fuentes TrueType similares a las utilizadas por Microsoft, plantillas y galerías de imágenes adicionales y parches y actualizaciones adiciona- les, entre otros. OpenOffice.org 33 utiliza un formato comprimido de archivos basado en XML para todas sus aplicaciones, que difiere de los formatos binarios utilizados por otras aplicaciones ofimáticas de propiedad. Este formado permite separar fá- (33) La mayoría de características de OpenOffice.org que se citarán en el apartado son extensibles a Sta- rOffice.
  • © FUOC • P08/M2104/00604 97 Implantación, proyectos y empresas de software libre cilmente el contenido del archivo de sus datos, sus estilos, el control de versio- nes y las imágenes incluidas en el documento. OpenOffice.org permite igual- mente trabajar con otros formatos basados también en XML. Migración￿de￿archivos￿en￿formato￿Microsoft￿Office OpenOffice.org incluye también mecanismos para convertir e importar archi- vos en formatos de propiedad, como los utilizados por el paquete ofimático Microsoft Office. De la misma manera, permite guardar archivos creados con OpenOffice.org en formatos de propiedad. Sin embargo, esta compatibilidad no es completa, y si bien la calidad suele ser en la mayoría de los casos aceptable, en ocasiones pueden aparecer dife- rencias en el formato de los documentos, sobre todo en aquéllos que incluyen elementos complejos, como macros u otras características especiales. En este caso puede ser que sea necesario reeditar algunos de estos documentos si se quiere que su formato sea idéntico al del original. Por ello, antes de convertir y migrar los documentos, hace falta estudiar las particularidades y clasificarlos según su uso y su complejidad técnica: • Documentos editables: tienen que ser convertidos a un nuevo formato interoperable, como ODT, de manera que puedan ser editados en el futuro. • Documentos de sólo lectura: podrían ser convertidos al formato PDF, lo cual simplifica considerablemente el proceso de migración. • Documentos sencillos: no contienen macros, gráficos de propiedad, for- matos o estilos o elementos complejos, como notas al pie, tablas e índices. Pueden migrarse fácilmente mediante un tratamiento por lotes (batch). • Documentos complejos: pueden contener macros, gráficos de propiedad y gráficos vectoriales, objetos OLE, objetos activos, referencias cruzadas, etc. Se pueden migrar, pero lo más probable es que exijan un tratamiento individual. OpenOffice.org ofrece la posibilidad de convertir un gran número de docu- mentos mediante un tratamiento por lotes. Todos los documentos se tendrán que encontrar en un directorio de origen y se especificará un directorio de destino, en el cual se guardarán todos los documentos convertidos. De todos modos, es recomendable verificar la exactitud de la conversión con una mues- tra representativa de todos los documentos. Por otra parte, cuando se trate de documentos complejos, hay dos posibilida- des:
  • © FUOC • P08/M2104/00604 98 Implantación, proyectos y empresas de software libre • Realizar la conversión documento a documento, de manera que se pue- dan corregir las eventuales diferencias con el documento original, antes de guardarlo en el nuevo formato. • Revisar los documentos uno a uno para eliminar los elementos que puedan afectar al proceso de conversión y, a continuación, realizar un tratamiento de todos ellos por lotes. Aplicaciones corporativas Por aplicaciones corporativas se entienden aquéllas que han sido desa- rrolladas a medida, para responder a las necesidades concretas de la em- presa u organización sobre la cual se lleva a cabo la migración. A los efectos de la migración, podemos distinguir entre los tipos de aplicacio- nes corporativas siguientes: • Aplicaciones que pueden ejecutarse sin problemas en un sistema operati- vo libre, como las aplicaciones multiplataforma (como las elaboradas en lenguaje Java) o las aplicaciones basadas en web (por ejemplo, en lenguaje PHP, como se ha visto en el apartado sobre servidores web). • Aplicaciones que exigen ligeras modificaciones a fin de que se puedan eje- cutar en un sistema operativo libre. Por ejemplo, para acceder correcta- mente a las bases de datos, como se ha visto en el apartado sobre este tema, o para configurar las nuevas variables de entorno. • Aplicaciones que pueden ejecutarse mediante emulación o virtualización. • Aplicaciones que no pueden ejecutarse en un sistema operativo libre. Por ejemplo, las aplicaciones implementadas en lenguajes exclusivamente pa- ra el sistema operativo de propiedad. La mayoría de aplicaciones corporativas son propietarios y en consecuencia la empresa no dispone del código fuente. En caso de que no sea posible ejecutar de ninguna manera la aplicación mediante emulación o virtualización, la op- ción más recomendable es implementar de nuevo la aplicación como software libre, basándose, a ser posible, en algún proyecto de software libre ya existente. 2.8. Formación, comunicación y soporte al usuario Hasta ahora se han presentado mayoritariamente los aspectos técnicos de la implantación de sistemas basados en software libre. La importancia de la tec- nología no debe esconder que uno de los factores de éxito de cualquier pro- yecto de implantación, y en especial en las situaciones de migración, es la aceptación del nuevo sistema por parte de sus usuarios.
  • © FUOC • P08/M2104/00604 99 Implantación, proyectos y empresas de software libre En este apartado se presentará en primer lugar los elementos principales del plan de formación en software libre en una organización y algunas buenas prácticas con el fin de facilitar la introducción y la aceptación de los usuarios. Para concluir, se repasarán los principales canales de comunicación y los ele- mentos fundamentales de un sistema de soporte al usuario. 2.8.1. Formación La formación adecuada de los usuarios tiene un papel importantísimo en el éxito del proyecto y, por lo tanto, tiene que estar prevista desde un primer momento en el plan del proyecto. A la hora de planificar la formación se tiene que identificar en primer lugar qué grupos de usuarios utilizarán unos tipos de aplicaciones concretas u otros. De esta manera se podrán estudiar las diferencias entre las aplicaciones de propiedad y las libres y, en consecuencia, evaluar la dificultad que supondrá la adopción de las nuevas aplicaciones para los usuarios. Con estos elementos será posible planificar una formación a la medida de las necesidades reales de cada usuario. Hay aplicaciones libres que son muy similares a sus equivalentes de propiedad, como los navegadores, los clientes de correo electrónico o las aplicaciones ofi- máticas. Es evidente que en estos casos la necesidad de formación será menor. Materiales Hay un gran número de materiales en Internet que pueden utilizarse para la formación de los usuarios o para preparar materiales propios. Hay que tener en cuenta que a menudo los manuales y la documentación es- tán disponibles sólo en inglés, lo cual puede suponer un problema para algu- nos de los usuarios. La interfaz de algunas aplicaciones no está traducida o su traducción es incompleta. En estos casos se puede considerar la edición de una documentación propia, orientada a solucionar los problemas de idioma. El proyecto europeo SELF proporciona una plataforma para crear y compartir materiales educativos sobre software libre y estándares abiertos. Responsable￿de￿la￿formación La formación puede realizarse dentro de la propia organización, en colabora- ción con una empresa externa o a través de una plataforma de aprendizaje en línea.
  • © FUOC • P08/M2104/00604 100 Implantación, proyectos y empresas de software libre En cualquiera de los casos, es importante facilitar tanto como sea posible el acceso a la formación y a sus materiales. Según la política de la organización, la asistencia a las actividades de formación puede ser obligatoria o no. Las plataformas de aprendizaje en línea ofrecen la ventaja que los usuarios pueden ajustar el proceso de aprendizaje y su acceso a la formación de acuer- do con sus necesidades. Moodle es un sistema de gestión de cursos libre que permite crear lo que se denominan comunidades￿de￿aprendizaje￿en￿línea, en la cual los alumnos pueden seguir la formación y comunicarse entre ellos. Una buena opción puede ser la combinación de formación presencial y un sistema de aprendizaje en línea. Finalmente, no se tiene que descartar el ofrecer algún tipo de incentivo a los usuarios para motivarlos a participar en la formación, por ejemplo la conce- sión de certificados de asistencia y de aprovechamiento. Tipos￿de￿usuarios Los usuarios no son todos iguales. En primer lugar, hay siempre algunos usua- rios que son más receptivos hacia el nuevo software que otros. No obstante, en la mayoría de los casos, una vez los usuarios han superado sus reservas ha- cia el uso del software libre lo encuentran muy similar al software propietario y están satisfechos con su utilización. Por lo tanto, no hay que preocuparse mucho en caso de que las primeras experiencias sean negativas. En segundo lugar, hay que tener en cuenta que el personal técnico y no técnico necesitará una formación y un seguimiento diferente. El personal técnico necesitará llevar a cabo un esfuerzo superior que el de los usuarios normales, especialmente si no tienen ninguna experiencia previa en software libre y algunos están habituados a trabajar con un sistema de pro- piedad que, en cambio, dominan perfectamente. Por otra parte, la participa- ción del personal técnico es muy importante para asegurar el funcionamiento del sistema una vez implantado. Una buena práctica es motivarlos y hacerlos partícipes del proceso de implantación, de manera que puedan hacer suyo el sistema mientras éste se va poniendo en marcha. 2.8.2. Introducción del software libre Al margen de la formación, otra de las prácticas que pueden facilitar el éxito de un proyecto de migración de software libre es introducir las nuevas aplica- ciones y servicios gradualmente, de manera que los usuarios tengan tiempo de ir habituándose al nuevo entorno y no se encuentren con un sistema to- talmente desconocido.
  • © FUOC • P08/M2104/00604 101 Implantación, proyectos y empresas de software libre Instalación￿de￿aplicaciones￿puente Hay un buen número de aplicaciones de escritorio cuyo uso está muy extendi- do y que están disponibles tanto en sistemas operativos de propiedad como en GNU/Linux, como el paquete ofimático OpenOffice.org, el navegador Firefox o el cliente de correo electrónico Thunderbird. Hay también diversos servicios o aplicaciones de servidor que se pueden ejecutar en ambos sistemas, como el sistema gestor de bases de datos MySQL y el servidor web Apache. Este tipo de aplicaciones se denominan aplicaciones puente y pueden ser muy útiles a la hora de empezar la migración 34 y evaluar la respuesta de los usuarios y precisar mucho mejor sus necesidades de formación. Migración￿escalonada￿de￿los￿servicios El primer objetivo de toda migración es conseguir una transición de un sistema a otro sin que los usuarios noten ninguna gran diferencia o, a ser posible, ninguna diferencia en absoluto. Una estrategia para conseguir este objetivo es empezar la migración en los servidores, de manera que los usuarios puedan continuar trabajando normalmente hasta que el sistema esté preparado para la migración de los clientes. Entre los servicios que se pueden migrar fácilmente al inicio hay los de red (DNS, DHCP, etc.), los servidores web y los servidores de bases de datos. Puede ser necesario el uso de soluciones tecnológicas que funcionen bien en sistemas heterogéneos, como OpenLDAP combinado con Samba. De esta manera se dispone también de bastante tiempo para formar al personal técnico, el apoyo del cual puede ser muy útil a la hora de migrar los clientes y dar soporte al resto de usuarios. Tanto la introducción de aplicaciones puente como la migración escalonada de servicios se tendrán que tener en cuenta en la planificación del proyecto. 2.8.3. Comunicación del proyecto Como se ha visto, la implantación y migración a un sistema basado en software libre es un proceso que implica a todos los usuarios de la organización, y no sólo al personal técnico encargado de su despliegue y mantenimiento. Es esencial disponer de mecanismos eficaces de comunicación entre los usua- rios y la dirección técnica y administrativa de la organización y garantizar la transparencia de todo el proceso, por lo que las actividades de comunicación tienen que estar definidas en el plan de proyecto, que tiene que incluir: • Comunicación￿inicial￿conjunta￿a￿todos￿los￿usuarios. Se explicará la mo- tivación y la planificación general del proyecto antes de su puesta en mar- (34) Sería una migración de aplica- ciones sencilla, como la que se ha visto en el apartado sobre tipos de migración.
  • © FUOC • P08/M2104/00604 102 Implantación, proyectos y empresas de software libre cha a través de reuniones informativas, notas o correos electrónicos inter- nos o anuncios en la intranet de la organización. • Comunicación￿periódica￿del￿avance￿del￿proyecto. Se indicarán qué par- tes del sistema se migrarán y cuándo, así como las eventuales modifica- ciones del proyecto. Se organizarán reuniones reducidas con los usuarios implicados en cada una de las fases de la migración. • Reuniones￿periódicas￿después￿de￿la￿finalización￿del￿proyecto. Se eva- luará el éxito del proyecto y se hará un seguimiento general de sus resul- tados, así como de las experiencias de los usuarios del sistema. 2.8.4. Sistema de soporte al usuario Un pilar fundamental del nuevo sistema es la puesta en funcionamiento de un sistema de gestión de incidencias a disposición de los usuarios, de manera que puedan resolver tanto sus dudas como los problemas técnicos derivados de la situación. Es importante dar una respuesta rápida y eficaz a todos estos problemas, sobre todo en los primeros momentos después de la implantación. A la hora de diseñar un sistema de soporte al usuario, hay que responder estas preguntas, que definirán las características principales del sistema: • ¿Quiénes son los usuarios? • ¿Cómo funciona la organización? • ¿Qué tipo de soporte necesitan los usuarios? • ¿Qué tipo de soporte se ofrecerá a cada tipo de usuario? • ¿Cuánto soporte se ofrecerá? • ¿Cómo se ofrecerá el soporte? La realización de pruebas piloto puede servir como base para caracterizar la mayoría de los problemas con que se encontrarán los usuarios, y así preparar un procedimiento para resolver cada uno de ellos. De la misma manera, se tendrán que identificar los servicios y los usuarios más importantes y críticos del sistema, que disfrutarán de un soporte preferente. Por otra parte, hay que tener en cuenta que más soporte representa un coste más elevado. Está la posibilidad de sobredimensionar el soporte en las prime- ras semanas después de la migración, cuando el número de consultas y de in- cidencias sea mayor. En cualquier caso, la clave para que un sistema de soporte al usuario sea eficaz es garantizar una comunicación fluida con los usuarios, de manera que éstos sean conscientes de que su problema se tiene en cuenta.
  • © FUOC • P08/M2104/00604 103 Implantación, proyectos y empresas de software libre Finalmente, es posible que antes de la migración ya existiera un sistema de soporte al usuario. En caso de que este sistema estuviera basado en software propietario, habría que evaluar las diferentes alternativas libres disponibles. Página web Existen numerosas solu- ciones. Se puede consul- tar una comparación en http://en.wikipedia.org/wi- ki/Comparison_of_ticket- tracking_systems.
  • © FUOC • P08/M2104/00604 104 Implantación, proyectos y empresas de software libre 3. La empresa del software libre Esta tercera unidad de la asignatura de "Implantación de sistemas en software libre" proporciona las bases para conocer los principales conceptos y caracte- rísticas ligados al negocio empresarial del software libre. Desde sus inicios, el software libre siempre ha estado presente a nivel de las tecnologías de la información. Su evolución a lo largo del tiempo se ha visto influida por los cambios estructurales que se han ido produciendo a nivel tec- nológico, económico y social. Con el paso del tiempo, se han puesto de manifiesto las diferentes filosofías en torno a la creación, producción y difusión del software. En términos generales, hay que destacar dos tendencias principales con características opuestas: • Por un lado, la filosofía propietaria, que defiende la protección del software con el cierre y privatización del código fuente, así como la imposición de licencias con fuertes restricciones para su utilización. • Por otra parte, la filosofía libre, que defiende la libertad del software y del código fuente con licencias que garantizan los derechos de los usuarios en la ejecución del programa, el estudio y la adaptación del código fuente y la redistribución y la publicación de las mejoras que se puedan introducir. Estas dos filosofías han generado modelos de negocio empresarial opuestos en la ideología, el funcionamiento, la operativa y la economía: • El modelo de software privativo normalmente establece un valor econó- mico que hay que sufragar mediante el uso restringido de una copia en formato binario, hecho que imposibilita la adaptación, corrección o me- jora del código fuente por parte de personas u organizaciones que no dis- ponen de los derechos de autoría, o del acuerdo explícito de los que los poseen. Hay que destacar que muchas licencias propietarias impiden ce- der los derechos de utilización a un tercero sin el previo acuerdo de los poseedores de los derechos de autoría. • El modelo de software libre tiende a centrarse en el desarrollo y la adapta- ción de soluciones libres y cualitativas que respondan a las necesidades de usuarios y organizaciones, así como los servicios complementarios para su puesta en marcha y funcionamiento habitual. En este sentido, el modelo de negocio basado en el software libre permite las actuaciones que impide o restringe el modelo de software privativo. Ved también Con el fin de conocer más as- pectos históricos del softwa- re libre, consultad el segundo punto de los materiales de la asignatura de "Introducción al software libre".
  • © FUOC • P08/M2104/00604 105 Implantación, proyectos y empresas de software libre La particular concepción filosófica del software libre no sólo influye directa- mente en el modelo de negocio y en la estrategia empresarial, sino también en la definición, la gestión, la organización y el funcionamiento de la empre- sa tecnológica. Aspectos como la madurez del software libre, la presencia de una comunidad mundial de colaboradores en proyectos de software libre y la viabilidad de los modelos de negocio reconfiguran el proyecto empresarial clásico de forma sustancial. El primer apartado de esta unidad se dedica a caracterizar a los diferentes mo- delos de negocio basados en el software libre, válidos y viables para ser lleva- dos a la práctica como estrategia empresarial. El segundo apartado se dedica íntegramente a la concepción del plan de ne- gocio empresarial y se detallan los principales aspectos ligados a la creación, organización, producción y funcionamiento de la empresa del software libre. El tercer apartado presenta la producción de software libre, con la caracteriza- ción de las principales particularidades en la creación, organización, comuni- cación y desarrollo del código fuente. Finalmente, esta unidad dispone de dos anexos en los cuales se presentan de forma breve y sistemática las principales licencias libres y estándares abiertos que tienen relación directa con el negocio del software libre. 3.1. Modelos de negocio En este primer apartado se presentan los principales modelos de negocio ba- sados en el software libre, así como las características y particularidades que lo diferencian de las tendencias de negocio basadas en software propietario. En general, la diferencia más significativa entre el software libre y el privativo desde el punto de vista empresarial es la licencia. A grandes rasgos, una licencia es un modelo contractual en el cual el autor del producto (o aquél que posee los derechos de autoría) establece los de- rechos y deberes de los usuarios del producto y el escenario en el cual los pueden utilizar. En este sentido, las licencias libres 35 se basan en cuatro principios básicos de libertad con respecto al software y su código fuente: • La libertad de ejecutar el programa con cualquier propósito. • La libertad de estudiar el código fuente y adaptarlo a las necesidades par- ticulares, por lo cual es necesario el acceso al código fuente. (35) Existe una cierta controver- sia entre la Free Software Foun- dation (http://www.fsf.org) y la Open Source Initiative (http:// www.opensource.org) a causa de las implicaciones de los términos li- bre y abierto.
  • © FUOC • P08/M2104/00604 106 Implantación, proyectos y empresas de software libre • La libertad de redistribuir copias del software. • La libertad de mejorar el software y publicar las mejoras, por lo cual es necesario el acceso al código fuente. Los principios básicos de libertad del software libre se contraponen al modelo privativo centrado en la explotación comercial de venta de licencias de utiliza- ción restringida del formato binario 36 , aunque no se exige que el software libre se tenga que obtener de forma gratuita. Sin embargo, buena parte del software libre existente en la actualidad se puede obtener mediante descarga directa y gratuita desde el portal en Internet de la organización que lo gestiona. Descargas directas y gratuitas Unos ejemplos de descargas directas y gratuitas: • Debian GNU/Linux de http://www.debian.org/distrib/ • FreeBSD de http://www.freebsd.org/where.html • KOffice de http://www.koffice.org/download/ • OpenOffice.org de http://download.openoffice.org/ La apertura filosófica del software libre favorece los modelos de negocio cen- trados en el capital humano, los conocimientos, la personalización y la ade- cuación de los productos, así como la evolución constante del software. En es- te sentido, es importante destacar el papel que juega la comunidad de usuarios del software libre, que vela por la calidad y por la evolución de los productos libres, con un rendimiento difícilmente igualable en modelos de propiedad. Recurso web Encontraréis la definición original de software libre en http://www.gnu.org/philo- sophy/free-sw.html. (36) En inglés, right-to-use licensing. Con el tiempo, el modelo del software libre ha consolidado una oferta que abarca la mayoría de sectores con presencia de software privativo, y ofrece un mercado maduro, cualitativo y seguro sobre el cual basar una estrategia em- presarial, tanto para el desarrollo de software como para los servicios comple- mentarios. En cierta manera, la estrategia de negocio del software libre se funda- menta en los aspectos diferenciadores con respecto al modelo de pro- piedad, por ejemplo la ampliación de funcionalidades, la adaptación personalizada, el elevado y constante número de revisiones, las garan- tías de seguridad y calidad de funcionamiento del producto, así como todo un abanico de servicios complementarios para la puesta en marcha y el funcionamiento habitual. Recursos web En http://freshmeat.net/ y http://sourceforge.net/ en- contraréis un amplio abanico de proyectos de software li- bre en las principales áreas de aplicación de la tecnología.
  • © FUOC • P08/M2104/00604 107 Implantación, proyectos y empresas de software libre En los siguientes apartados se presentan los principales modelos de negocio que se derivan de la filosofía conceptual del software libre: desarrollo, consul- toría, instalación e integración, migración, mantenimiento y soporte y forma- ción. Los modelos de negocio que se presentan no deben entenderse como inde- pendientes, sino como complementarios. Es decir, puede convenir la combi- nación de dos o más modelos de negocio para dar respuesta a la estrategia empresarial. 3.1.1. Desarrollo El modelo de negocio de desarrollo de software se basa en la producción total o parcial de un producto basado en software libre destinado a su comercialización, ya sea directamente o bien en el marco de un proyecto de implantación por cuenta ajena, como los presentados en la segunda unidad de la asignatura. La definición de software libre no hace ninguna referencia con respecto a la estrategia de vender un producto libre a un precio por copia vendida, pero las características de las licencias libres convierten esta posibilidad en una opción secundaria, aunque sobradamente utilizada por algunas organizaciones. Productos libres empaquetados Algunas organizaciones deciden ofrecer sus productos libres empaquetados (caja, discos, manuales, documentación, etc.) a cambio del abono de un importe que, a pesar de ser inferior al precio de soluciones alternativas, es superior al precio de coste. Por ejemplo, se puede comprar la distribución Ubuntu en http://www.ubuntu.com/getubuntu/purchase. En general, la producción de software libre responde principalmente a la venta de servicios complementarios de valor añadido para el cliente, que también sirven para sustentar la continuidad del software, por ejemplo la personaliza- ción y adecuación a un entorno determinado. En los materiales de la asignatura de "Introducción al software libre" se ofrece una clasificación de las posibles alternativas del desarrollo de software libre, reproducida brevemente a continuación: • Mejor￿conocimiento. Se basa en el propósito de rentabilizar el conoci- miento sobre uno o más productos libres, ofreciendo desarrollos a medida, modificaciones o adaptaciones (entre otros que se presentarán más ade- lante). La participación activa en la creación y desarrollo de los productos libres es el valor añadido de la empresa ante el cliente y la competencia. • Mejor￿ conocimiento￿ con￿ limitaciones. Se basa en el modelo anterior (mejor conocimiento) pero con una implementación mixta de licencias libres y de propiedad (o eventualmente patentes) para reducir la compe- Ved también Encontraréis más información y ejemplos de esta clasificación en el apartado 5.2 "Modelos de negocio basados en softwa- re libre" de los materiales de la asignatura de "Introducción al software libre".
  • © FUOC • P08/M2104/00604 108 Implantación, proyectos y empresas de software libre tencia. Este modelo puede resultar inviable si el producto libre se escinde en una rama soportado por la comunidad libre, de manera que podría de- saparecer la ventaja competitiva. • Fuente￿de￿un￿producto￿libre. Es similar al primer modelo (mejor conoci- miento) con la diferencia que la empresa es la productora del código de forma casi íntegra. El cliente valora el posicionamiento y la ventaja com- petitiva con respecto a la competencia. Este modelo recibe el soporte de la comunidad libre. • Fuente￿de￿un￿producto￿con￿limitaciones. Se basa en el modelo anterior (fuente de un producto libre) pero con una implementación orientada a reducir la competencia, por ejemplo iniciando la distribución bajo licencia privativa y liberándose más adelante, o haciendo que la distribución inicial se limite a los clientes de la empresa. • Licencias￿especiales. Se basa en la producción de un mismo producto que se distribuye bajo diferentes licencias, libres y propietarias. El producto de propiedad se orienta a implementaciones especiales del producto, como la integración con otros productos propietarios. • Venta￿de￿marca. Se basa en la distribución de productos libres con una imagen de marca empresarial, que da calidad y valor añadido desde el pun- to de vista del cliente. Normalmente, estos productos se acompañan de numerosos servicios adicionales a los clientes. La selección de la tipología de negocio asociada al desarrollo de software tie- ne que coordinarse principalmente con la estrategia empresarial y el mercado objetivo. En este sentido, una organización puede decidir usar una tipología personalizada para cada uno de los productos que pretenda introducir en el mercado, en función de la estrategia y el mercado objetivo particular que per- siga en cada uno de ellos. El modelo de negocio de desarrollo de software libre también exige la selección esmerada de las licencias del código fuente que manipula: • La licencia del código fuente que modifica, si el producto final es una me- jora de un producto que ya existía antes. • La licencia del código fuente que enlaza, si el producto final requiere para su operativa implementar llamadas en funciones de bibliotecas externas. • La licencia del código fuente que crea, es decir, cuando el código fuente es completamente nuevo.
  • © FUOC • P08/M2104/00604 109 Implantación, proyectos y empresas de software libre • La licencia del código fuente del producto final, que considera el conglo- merado de código fuente del producto final. La importancia de determinar esmeradamente la licencia asociada a cada parte del código fuente que se manipula radica en la existencia de diferencias entre las diversas licencias libres. Es decir, aunque todas las licencias libres garanti- zan las cuatro libertades básicas, difieren en la política de licenciamiento de la redistribución de código modificado, que es precisamente el objeto del mo- delo de negocio de desarrollo de software libre. En el anexo I de esta unidad presentamos brevemente las características más importantes de las principales licencias del software libre y exponemos la po- lítica de redistribución y las compatibilidades del enlace y de la obra derivada. La selección y combinación adecuada de licencias influye directamente en la producción de software libre, y puede tener implicaciones legales si no se realiza esmeradamente. En el último apartado de esta unidad, dedicado a la producción de software libre, se profundizará en la selección de la licencia más adecuada a partir de los parámetros del producto. Finalmente, hay que decir que el software libre promueve y utiliza especifi- caciones públicas, denominadas estándares abiertos, con el fin de favorecer la universalidad y la interoperabilidad de los formatos que manipulan. En el anexo II de esta unidad didáctica presentamos brevemente las principales ca- racterísticas y ejemplos de los estándares abiertos. 3.1.2. Consultoría El modelo de negocio de consultoría se basa en la producción de ser- vicios profesionales complementarios al software libre para usuarios y organizaciones. En cierta manera, este modelo de negocio se centra en el objetivo de proveer servicios tecnológicos profesionales externos de calidad a organizaciones que no asumen totalmente la creación, la gestión, el desarrollo y la evaluación de sus proyectos tecnológicos internos. La diversidad de servicios profesionales que pueden ofrecer las consultorías es elevado, y dependerá de la estrategia y el entorno a actividad empresarial. Sin embargo, tienen una fuerte relación con las actividades de estudio, análisis, diseño y evaluación propias del proyecto de implantación de sistemas de soft- ware libre presentado en la segunda unidad de este módulo. Ved también En el apartado "Clasificación por ámbito" de la primera uni- dad encontraréis más informa- ción de la tipología de proyec- tos productivos.
  • © FUOC • P08/M2104/00604 110 Implantación, proyectos y empresas de software libre A continuación, presentamos una clasificación breve de los principales servi- cios que una consultoría puede ofrecer a sus clientes: • Gestión￿de￿proyectos: se basa en el propósito de realizar las funciones de creación y gestión funcional del proyecto de implantación de software libre. Las tareas que desarrolla este servicio se relacionan con el ciclo de vida del proyecto, la gestión de los equipos de profesionales involucrados en cada etapa del proyecto, el control del progreso efectivo del proyecto y, en general, todas aquellas tareas de coordinación, información, gerencia y seguimiento del proyecto. • Ejecución￿de￿etapas￿de￿análisis￿y￿diseño￿del￿proyecto: se basa en el pro- pósito de realizar una o más etapas de análisis y diseño del proyecto de implantación de un sistema en software libre. Las tareas que desarrolla es- te servicio se relacionan con los encargos de la contratación, por ejemplo el estudio del sistema actual, el estudio de requerimientos del nuevo siste- ma, el análisis de soluciones en software libre y/o el diseño de un nuevo sistema, de acuerdo con las etapas presentadas en la segunda unidad del módulo. • Evaluación￿y￿auditoría: se basa en el propósito de realizar valoraciones tecnológicas profesionales de una o más características de sistemas en fun- cionamiento. Las tareas que desarrolla este servicio pueden estar enmarca- das dentro de un proyecto de implantación de sistemas, como sería el ca- so de la ejecución de etapas visto anteriormente, pero también se pueden desarrollar de forma independiente y aislada. La evaluación o la auditoría se centra en valorar uno o más aspectos del sistema, como la seguridad, el rendimiento, la eficiencia o la eficacia (entre otros), y se puede realizar antes y/o después de la implantación del sistema. • Asesoría: se basa en el propósito de dar soporte, ayuda y consejo profe- sional a la toma de decisiones tecnológicas en la organización. Las tareas que desarrolla pueden tener lugar antes del inicio de cualquier proyecto de implantación o bien en las fases de estudio, análisis y diseño, pero se enmarcan en el soporte profesional a decisiones estratégicas tecnológicas para el futuro de la organización. La lista presentada no se tiene que considerar ni exhaustiva ni excluyente, ya que el modelo de negocio puede estructurar dos o más servicios para responder a la estrategia empresarial. Adicionalmente, el modelo de negocio de consul- toría puede combinarse con otros modelos de negocio para ofrecer al cliente un servicio tecnológico integral. Ampliando información En el apartado "Tipologia de proyectos" de la primera uni- dad y en el apartado "Ciclo de vida" de la segunda unidad en- contraréis más información so- bre la gestión y el ciclo de vida de los proyecto de software li- bre. Ved también En los apartados "Estudio de la situación actual", "Estudio de los requisitos de la implanta- ción", "Análisis de las solucio- nes en software libre" y "Desa- rrollo" de la segunda unidad encontraréis más información sobre el estudio del sistema actual, el estudio de requeri- mientos del sistema, el análi- sis de las soluciones en softwa- re libre y el diseño del sistema, respectivamente.
  • © FUOC • P08/M2104/00604 111 Implantación, proyectos y empresas de software libre En este sentido, el mejor conocimiento de las plataformas tecnológicas im- plantadas (o que hay que implantar), así como la excelencia para el análisis y extracción de información y conclusiones, o el alcance y la complejidad del proyecto, son características decisorias a fin de que la organización decida ex- ternalizar la gestión o las etapas de la implantación. Normalmente, los trabajos de consultoría se formalizan con contratos abiertos o cerrados. En los contratos abiertos la relación se origina a partir del encargo de un servicio determinado y, en función del resultado del servicio, el contrato se amplía con el encargo de nuevos servicios. Por ejemplo, la ejecución de una o más etapas del proyecto puede estar sujeta a contratos abiertos. En cambio, en los contratos cerrados se adjudica el cumplimiento de un de- terminado objetivo, función, resultado o trabajo, sin posibilidad directa de ampliar la contratación en el mismo escenario. Por ejemplo, la auditoría in- dependiente de un sistema puede estar sujeta a contratos cerrados, dadas las eventuales características temporales de puntualidad y aislamiento. 3.1.3. Instalación e integración El modelo de negocio de instalación e integración se basa en la implan- tación directa de sistemas en software libre para usuarios y organizacio- nes, normalmente enmarcados en proyectos de software libre. En cierta manera, este modelo de negocio considera el software libre como objeto para la producción de servicios, más que como producto en sí mismo. De esta forma, se fundamenta un mercado en el cual se resaltan los beneficios para el cliente: • La organización no tiene que pagar licencias en productos de software libre que se distribuyen de forma gratuita y, por consiguiente, puede reducir el coste de implantación tecnológica. • La organización no tiene que recurrir a la piratería de productos y, por consiguiente, no incumplirá la legalidad vigente. • La organización puede adaptar directamente las soluciones libres y, por consiguiente, podrá disminuir el coste de implantación de sistemas espe- cializados. • La organización puede adoptar paquetes integrados de implantación di- recta y, por consiguiente, reducirá el riesgo de implantación tecnológica.
  • © FUOC • P08/M2104/00604 112 Implantación, proyectos y empresas de software libre A continuación presentamos una lista breve de los principales servicios que puede ofrecer este modelo de negocio, aunque la lista no es exhaustiva ni excluyente de otros servicios: • Configuración: se trata de realizar las tareas de configuración y ajuste 37 de un sistema ya implantado con el objetivo de formalizar la configuración inicial, mejorar su rendimiento o ajustarlo a nuevos propósitos no consi- derados inicialmente. En cualquier caso, los ajustes que se introducen no modifican el código fuente de la aplicación, únicamente la configuración de aquellos componentes que permitan el ajuste a las características par- ticulares de la instalación. (37) En inglés, set-up o tune-up. • Pruebas: se trata de proporcionar un banco de pruebas de sistemas, apli- caciones o soluciones en software libre bajo una perspectiva determinada. Puede tratarse de un análisis comparativo de soluciones libres, las pruebas de un nuevo diseño de sistema, o el test de software de implantación di- recta sobre hardware específico, ya sea en el marco de un proyecto de im- plantación, o bien como pruebas independientes y aisladas. • Integración: se trata de realizar y/o comprobar la integración entre dos o más soluciones de software libre, con el objetivo de proporcionar un pa- quete único que resuelva una función operativa concreta 38 . Normalmente, esta integración se puede resolver con la configuración apropiada de cada elemento y, eventualmente, con algún componente adicional que permita la integración con más eficiencia. Ampliando información En los apartados "Análisis de las soluciones en software li- bre", "Desarrollo" e "Implanta- ción y migración" de la segun- da unidad encontraréis más in- formación sobre el análisis de las soluciones en software li- bre, el diseño del sistema y la implantación y migración del sistema, respectivamente. (38) Por ejemplo, LAMP (Linux, Apa- che, MySQL, PHP) es un paquete integrado de software con diferen- tes objetivos particulares, pero que conjuntamente soluciona una pro- blemática concreta de forma efi- ciente y eficaz. • Instalación: se trata de realizar la instalación masiva de software de im- plantación directa en máquinas clientes o servidores 39 . Este servicio pue- de necesitar la configuración y el ajuste tanto del software libre que se pretende instalar como del hardware receptor de la instalación. También puede ser necesaria la integración de las diferentes soluciones que se pre- tenden instalar. En los casos en los cuales se tenga que implantar el mismo software en un conjunto de ordenadores con idéntico hardware, puede resultar útil usar software de clonado y distribución de imágenes precon- figuradas para ahorrar tiempo y coste, además de mejorar la eficiencia y eficacia del proceso. (39) En inglés, sería similar al térmi- no installfest, pero aplicado al ne- gocio estructurado. • Distribución: se trata de redistribuir software libre a los clientes, ya sea en el format original 40 o bien en configuraciones personalizadas en relación con el ámbito de negocio empresarial; por ejemplo la integración de he- rramientas, la orientación operativa a cliente, a servidor o a estación de trabajo41 , entre otros. La redistribución de software integrado está sujeta a las licencias de las soluciones particulares. En el anexo I se presentan las principales licencias de software libre y su compatibilidad. (40) En http://freshmeat.net/ y http://sourceforge.net/ encontra- réis un amplio abanico de proyec- tos de software libre en las princi- pales áreas de aplicación de la tec- nología. (41) En inglés, workstation.
  • © FUOC • P08/M2104/00604 113 Implantación, proyectos y empresas de software libre Tal como se desprende de la clasificación anterior, estos servicios tienen una fuerte relación con las etapas de análisis de las soluciones en software libre y de implantación y migración del proyecto de implantación presentado en la segunda unidad. En este sentido, el mejor conocimiento de las plataformas tecnológicas, así como la excelencia y eficiencia de los servicios, o el alcance y la complejidad del proyecto, son características decisorias a fin de que la organización decida externalizar la instalación y la integración del sistema. 3.1.4. Migración de sistemas El modelo de negocio de migración de sistemas se basa en el hecho de trasladar la operativa de funcionamiento entre el sistema implantado y el nuevo sistema que hay que implantar. La migración es un proceso complejo, que hay que ejecutar con la precisión y el rigor necesarios de acuerdo con la importancia que suponen los datos y configuraciones como capital para la organización. La diversidad de situaciones con que se pueden encontrar las empresas que se dedican a la migración de sistemas son fruto de la combinación entre las plataformas de origen y de destino de la migración. El conocimiento profun- do de las plataformas y la experiencia en la migración fundamentan el valor añadido para el cliente. A continuación presentamos una lista breve de los principales servicios que ofrece este modelo de negocio, aunque la lista no es exhaustiva ni excluyente de otros servicios: Ved también En el apartado "Implantación y migración" de la segunda unidad encontraréis sobrada- mente detalladas las características de la migración de sistemas. Concretamente, en el apartado "Migración de los servicios de un sistema" encontraréis más información de los servicios que aquí presentamos. • Servicios de sistema de ficheros, tanto de servidor como de clientes. • Servicios de impresión, tanto entre clientes como entre servidores. • Servicios de directorio y de autentificación centralizada. • Servicios de red, especialmente de protocolos de gestión automatizada de control de la red, de las comunicaciones y de los clientes. • Gestión y administración del sistema, tanto la gestión de la red como del software.
  • © FUOC • P08/M2104/00604 114 Implantación, proyectos y empresas de software libre • Servicios web, tanto con plataformas estáticas como dinámicas. • Bases de datos, tanto la migración de los datos como la verificación de los accesos. • Entornos de escritorio y aplicaciones de ofimática, tanto las aplicaciones como los datos de usuario. • Aplicaciones corporativas, tanto las aplicaciones que se pueden ejecutar directamente, como las que exigen ajustes o virtualizaciones. La complejidad y el alcance de la migración, la capacidad de realizar el proceso de forma esmerada, eficiente, eficaz y con el menor tiempo posible, así como el mejor conocimiento de las plataformas tecnológicas de origen y de destino de la migración son características decisorias a fin de que la organización decida externalizar la migración del sistema. Tal como se puede concluir de la clasificación de los servicios que hemos pre- sentado, el proceso de migración puede necesitar otros servicios, como la ins- talación, la configuración, la integración o las pruebas para asegurar la conse- cución de los objetivos. El software libre utiliza y fomenta los estándares abiertos para el intercambio interoperable de los datos y es especialmente relevante su papel en la migra- ción de los sistemas. Por ejemplo, partir de un sistema que no almacene los datos en estándares abiertos podría complicar la migración a causa de la con- versión de los formatos, especialmente si el original es privativo. En el anexo II de este módulo didáctico presentamos los estándares abiertos, su definición, los organismos que los impulsan y algunos ejemplos. 3.1.5. Administración y mantenimiento de sistemas El modelo de negocio de administración y mantenimiento de sistemas se basa en realizar las tareas de gestión y seguimiento de un sistema ya implantado y en funcionamiento. El principal objetivo de los servicios que puede ofrecer este modelo de nego- cio es mantener funcional todo el sistema a lo largo del tiempo, ajustando la configuración a los cambios que se produzcan, solucionando problemáticas que puedan surgir y reparando las averías que impidan el funcionamiento ha- bitual de la organización.
  • © FUOC • P08/M2104/00604 115 Implantación, proyectos y empresas de software libre A continuación presentamos una lista breve de los principales servicios que ofrece este modelo de negocio, aunque la lista no es exhaustiva ni excluyente de otros servicios: • Administración: consiste en proporcionar la gestión principal del siste- ma, el ajuste necesario con el paso del tiempo, la supervisión del funcio- namiento, la implantación de nuevas funcionalidades y la evolución del sistema. Muchas de las tareas de administración del sistema se pueden eje- cutar de forma remota 42 . • Mantenimiento￿y￿evolución: consiste en proporcionar supervisión, se- guimiento y corrección de las incidencias que se puedan originar en el sistema y que impidan su funcionamiento, así como el control y evolu- ción de la obsolescencia de los componentes. Por ejemplo, las averías y la desconfiguración de hardware o de software, el control y actualización de versiones de software, o el plan de evolución de hardware y software. • Seguridad: consiste en proporcionar la gestión de la seguridad del sistema, controlando los riesgos, manteniendo políticas de prevención, contingen- cia, diagnóstico y corrección de fallos. Por ejemplo, copias de seguridad o el control y mantenimiento de claves y certificados. Dadas las características y particularidades de estos servicios, muchas organi- zaciones deciden mantener trabajadores en plantilla que realicen estas tareas, pero algunas organizaciones pequeñas o medias no tienen bastante capacidad para asumir esta figura. (42) Por ejemplo, el uso conjunto de ssh, cron y at. También hay que tener en cuenta que la externalización de algunos servicios, como servidores de intranet y de extranet, pueden motivar la contratación de servicios externos de administración y mantenimiento. Normalmente, estos servicios funcionan con contratos con cuota fija mensual o anual para una determinada cobertura de servicios. 3.1.6. Soporte y formación El modelo de negocio de soporte y formación consiste en proporcionar ayuda técnica profesional para la educación y aprendizaje tecnológico de usuarios y la resolución de incidencias y problemas relacionados con la explotación del sistema. La implantación de sistemas en software libre puede necesitar medidas de so- porte y formación a los usuarios durante los primeros momentos de utiliza- ción, especialmente si el sistema anterior estaba basado en software privativo. Tal como se ha visto en el segundo módulo de la asignatura, el proyecto de implantación tiene que tener en cuenta la necesidad de actuar en el aprendi- Intranet y extranet Los servicios web, de intranet o de extranet son fácilmente externalizables gracias a la pro- liferación de los hoteles de da- tos (Data Hotels) o centros de datos (Data Centers).
  • © FUOC • P08/M2104/00604 116 Implantación, proyectos y empresas de software libre zaje de los usuarios para favorecer la gestión del cambio, el cual, junto con sus particularidades, hace que acabe siendo un servicio fácilmente externalizable a empresas especializadas en este sector. A continuación presentamos una lista breve de los principales servicios que ofrece este modelo de negocio, aunque la lista no es exhaustiva ni excluyente de otros servicios: • Formación: se propone proporcionar educación y aprendizaje sobre he- rramientas de software libre a usuarios finales, por ejemplo sistemas ope- rativos o herramientas de ofimática. Este servicio también puede incluir la formación de software especializado resultante del desarrollo producido en el proyecto de implantación de sistemas, por lo que puede resultar con- veniente para la gestión del cambio coordinar los esfuerzos con el equipo de implantación. Ved también En el apartado "Formación, co- municación y soporte al usua- rio" de la segunda unidad en- contraréis más información so- bre la formación y el soporte al usuario. • Soporte: se propone proporcionar asistencia técnica a los usuarios ante problemas cotidianos. Muchos de estos servicios se implementan en cen- tros telefónicos de ayuda 43 , aunque también puede resultar útil ofrecer bu- zones de correo electrónico para la resolución de incidencias o mensaje- ría instantánea 44 con un profesional. También puede resultar convenien- te combinar los esfuerzos con el equipo del proyecto de implantación de sistemas con el fin de resolver posibles errores del software implantado. En general, este modelo de negocio pide recursos humanos, tecnológicos y materiales adecuados a los objetivos de la formación: (43) En inglés, call centers. (44) En inglés, instant messaging o chat. • Recursos humanos con conocimientos profundos de la temática y con ca- pacidad para transmitir los conocimientos y resolver problemas. • Recursos tecnológicos adecuados a la formación y el soporte, por ejemplo plataformas tecnológicas de ayuda a la educación o centros telefónicos de asistencia técnica. Recurso web Por ejemplo, Moddle es una plataforma de educación a distancia basada en software libre. http://moodle.org/. • Recursos materiales adecuados a la formación, como documentación y ma- nuales específicos de software libre 45 bajo licencias libres. La calidad de estos parámetros es fundamental a fin de que la organización decida externalizar los servicios de formación y soporte. Normalmente, los servicios de formación se contratan por cursos con estructura acordada pre- viamente, mientras que los servicios de soporte se contratan por cuotas men- suales o anuales, con acuerdo previo de los servicios cubiertos. (45) El proyecto SELF proporciona una plataforma europea para crear y compartir materiales educativos relacionados con el software libre y los estándares abiertos (http:// selfproject.eu/).
  • © FUOC • P08/M2104/00604 117 Implantación, proyectos y empresas de software libre 3.2. Plan de empresa Un plan de empresa o de negocio es un instrumento que identifica, describe y analiza una oportunidad de negocio, examina su viabilidad y desarrolla los procedimientos y estrategias para crear la empresa que explote la oportunidad de negocio. Aclaración En este apartado se utilizará preferentemente el término plan de empresa, ya que el ob- jetivo del apartado es presentar los elementos necesarios para la creación de una empresa de software libre, como la ilustrada en el caso Cometa Technologies, que se verá en el segundo apartado. De acuerdo con esta definición, los objetivos del plan de empresa son los si- guientes: • Realizar un estudio de mercado que posicione el proyecto empresarial y determine su viabilidad técnica, económica y financiera • Desarrollar las medidas necesarias para conseguir los objetivos fijados en el mismo plan de empresa • Realizar un seguimiento de la evolución de la empresa y evaluar las des- viaciones respecto al plan de empresa inicial • Servir como tarjeta de presentación del proyecto y de los emprendedores a fin de obtener financiación y apoyo de terceros Si bien los tres primeros objetivos son principalmente de uso interno, el últi- mo es de uso externo y visible por personas ajenas al proyecto, al menos en principio. Durante la preparación de un plan de empresa hay que tener en cuenta siempre esta doble finalidad: servir como plan de proyecto y, a la vez, como presentación del proyecto. Por supuesto, hay que evitar la tentación de omitir los riesgos o aspectos ne- gativos del proyecto a fin de hacerlo más atractivo a los inversores. De hecho, la falta de estos elementos podría volverse en contra del propio proyecto em- presarial, ya que estaría basado sobre supuestos falsos. Por ello, la veracidad de los aspectos técnicos y económicos es uno de los requisitos básicos a la hora de redactar un plan de empresa. Ved también En el apartado 10.2 "Licencias de otros recursos libres" del material de la asignatura de Introducción al software libre encontraréis dos licencias de documentación, materiales y obras literarias sobradamente utilizadas en la actualidad.
  • © FUOC • P08/M2104/00604 118 Implantación, proyectos y empresas de software libre Todo plan de empresa debe responder a una serie de preguntas sobre el proyec- to que se desea poner en marcha: ¿quién?, ¿qué?, ¿por qué?, ¿dónde?, ¿cuán- do? y ¿cuánto? • ¿Quién? El nombre de la empresa, la marca de los productos o servicios ofrecidos, los nombres y trayectoria de los promotores. • ¿Qué? La descripción de los productos o servicios ofrecidos, los mercados a los que se dirigen y la cuota de mercado que se fija como objetivo, entre otros. • ¿Por￿qué? En general, todo plan de empresa busca obtener y maximizar los beneficios económicos. Sin embargo, esto no es incompatible con otros objetivos como la mejora de la calidad de vida de la sociedad o la creación de empleo. • ¿Dónde? La zona geográfica en la que se van a comercializar los productos o servi- cios, por ejemplo regional, nacional o internacional. Los canales de distri- bución que se van a utilizar, incluyendo los posibles acuerdos con otras empresas que permitan acceder a otras regiones. • ¿Cuándo? El inicio previsto de la actividad empresarial y su planificación posterior, incluyendo condiciones o limitaciones temporales que puedan afectar a la empresa, como los trámites de obtención de licencias, el tiempo de pro- ducción, la obsolescencia de determinadas tecnologías o la estacionalidad. • ¿Cuánto? La inversión inicial necesaria para poner en marcha el proyecto empresa- rial, la facturación mínima necesaria y la deseada, el umbral de beneficios y pérdidas, la reinversión de los beneficios y la repartición de dividendos, entre otros. Estas cuestiones se traducen en los siguientes aspectos que se encuentran en casi todo plan de empresa: • Resumen ejecutivo • Introducción • Descripción del negocio • Organización de la producción
  • © FUOC • P08/M2104/00604 119 Implantación, proyectos y empresas de software libre • Organización interna y recursos humanos • Estudio de mercado • Plan de marketing • Análisis económico-finaciero • Forma legal • Gestión de riesgos • Resumen y evaluación Dependiendo de la naturaleza de la empresa o negocio cada uno de estos as- pectos tendrá mayor o menor importancia en el plan de empresa y podrá or- ganizarse de diferentes maneras. En los apartados que veremos a continuación se revisará cada uno de estos aspectos y se estudiará su relación con los modelos de negocio basados en software libre vistos en el apartado anterior. 3.2.1. Resumen ejecutivo El resumen o sumario ejecutivo es una nota breve 46 que aparece al prin- cipio del plan de empresa y que resume los elementos principales del documento. De esta manera, permite que por ejemplo potenciales in- versores puedan hacerse una idea completa del plan de empresa, sin necesidad de entrar en los detalles de cada uno de los apartados. El resumen ejecutivo debe repasar prácticamente todos los aspectos del plan de empresa, a saber: • Descripción del modelo de negocio, prestando especial atención a la ca- dena de valor y la fuente de ingresos. • Breve descripción del los promotores del proyecto, su formación, sus co- nocimientos y habilidades, su trayectoria profesional y su dedicación al nuevo proyecto. • Descripción concisa del mercado, incluyendo tamaño, clientes, potencial de crecimiento y barreras. (46) En cualquier caso, su extensión no debería superar las tres páginas.
  • © FUOC • P08/M2104/00604 120 Implantación, proyectos y empresas de software libre • Análisis de las áreas funcionales del proyecto: producción, calidad y orga- nización de los recursos humanos. • Resumen del análisis financiero del proyecto y de la inversión necesaria para su puesta en marcha. • Resumen de los riesgos asociados al proyecto y los planes para prevenirlos y remediarlos. Resulta obvio que el resumen ejecutivo debe destacar los puntos fuertes del plan de empresa, especialmente en lo que se refiere al modelo de negocio que se desea desarrollar, la estrategia que se va emplear para ello y el equipo pro- motor. Se recomienda redactarlo una vez el plan de empresa está terminado y hacerlo desde cero, es decir, evitando reutilizar textos ya escritos. 3.2.2. Introducción A continuación del resumen ejecutivo y el índice, el primer elemento del plan de empresa debe ser una introducción que presente el nombre de la futura empresa 47 y el equipo promotor, así como el resto de profe- sionales involucrados en la redacción del plan de empresa. La presentación del equipo promotor debe incluir, como hemos visto, el his- torial profesional de cada uno de sus miembros y los conocimientos que apor- tan al proyecto empresarial. Es bastante frecuente que una parte del equipo promotor tenga un perfil especializado en gestión empresarial, pero que tam- bién cuente con especialistas en determinadas áreas tecnológicas, como en el caso de las empresas que trabajan con software libre. Por último, la introducción debe proporcionar una breve descripción de los diferentes apartados del plan de empresa que se desarrollarán posteriormente. Misión y visión La introducción es un buen lugar para presentar la misión y la visión de la nueva empresa, de manera que el lector pueda comprobar como estos dos conceptos se desarrollan en el plan de empresa. La misión y la visión de una organización permiten definir de una manera concisa sus principales características y objetivos y las estrategias para llevarlos a cabo. (47) En el caso de que el plan des- criba un nuevo producto o servicio de una empresa ya constituida, es conveniente presentar un resumen de su actividad, su evolución histó- rica, su tamaño, etc.
  • © FUOC • P08/M2104/00604 121 Implantación, proyectos y empresas de software libre La misión consiste en una frase concisa que justifica la existencia de la organización, es decir el propósito básico hacia el que apuntan sus actividades, y los valores que guían las actividades de sus empleados. La misión está fuertemente vinculada a los valores internos de la orga- nización, y describe en buena medida cómo competir y generar valor al cliente. La visión es también una frase concisa que describe las metas a medio y largo plazo de la organización. La visión está orientada al mercado y debe expresar de una manera colorista y visionaria cómo quiere la organización ser percibida por el mundo. Las principales diferencias entre misión y visión se resumen en lo siguiente: • La misión describe los aspectos internos de la organización y su funciona- miento, mientras que la visión describe los aspectos externos. • La misión tiene su horizonte en el corto y medio plazo, poniendo especial énfasis en los aspectos que se deben poner en práctica inmediatamente en la organización, mientras que la visión se fija a medio y largo plazo y da las líneas generales de la evolución de la organización en el futuro. Corcaribe Tecnología y eZ Systems La empresa Corcaribe Tecnología, especializada en productos y servicios basados en soft- ware libre, se fija la siguiente misión: "Corcaribe Tecnología provee soluciones tecnológicas que generan valor agregado bajo un modelo de negocio que permite ofrecer a sus clientes el mejor coste por los resultados entregados, produciendo auténticos beneficios tangibles e intangibles a sus miembros y colaboradores." Y la siguiente visión: "Convertirse en referencia latinoamericana de continuo éxito en la implementación de soluciones tecnológicas integrales aplicando preceptos y valores del conocimiento libre dentro de un modelo de desarrollo sustentable." Del mismo modo, eZ Systems, que ofrece software libre de gestión de contenidos se pro- pone la siguiente misión: "Ser la primera plataforma de gestión de contenidos en 2012." Y la siguiente visión: "Ayudar a las empresas a gestionar, publicar y compartir la información." La definición de una misión y una visión no es imprescindible en un plan de empresa, pero puede ayudar a sintetizar los objetivos a corto, medio y largo plazo del proyecto empresarial y a transmitirlos eficazmente a los potenciales inversores.
  • © FUOC • P08/M2104/00604 122 Implantación, proyectos y empresas de software libre 3.2.3. Descripción del negocio Es recomendable comenzar este apartado con una descripción de la empresa que se desea crear y con una breve presentación de los promotores del proyec- to, aunque ya se haya realizado previamente en la introducción. El objetivo esencial de este apartado es describir los productos o servicios para los cuales se está realizando el plan de empresa o de negocio, así como el modelo de negocio bajo el que van a ofrecerse, tal como se ha visto en el apartado anterior. Se debe prestar especial atención a explicar las particularidades de los modelos de negocio basados en software libre y tener siempre en cuenta que el lector del plan de empresa no tiene por qué estar familiarizado con ellos; por ejemplo, en los aspectos relacionados con la protección de la propiedad intelectual y los derechos sobre los productos o servicios. Del mismo modo, es conveniente explicar las necesidades que los productos o servicios van a cubrir y las principales diferencias respecto a la oferta ya existente, a fin de mostrar que el proyecto empresarial está bien posicionado en el mercado. Finalmente, es necesario presentar la capacidad de producción y prestación de servicios, lo que servirá de introducción al próximo apartado dedicado a la organización de la producción. 3.2.4. Organización de la producción Dentro del plan de empresa, el apartado dedicado a la organización de la producción aporta una descripción de las tareas técnicas de la futura empresa. Hasta ahora se ha contemplado la posibilidad de que el plan de empresa o de negocio describa la comercialización de un nuevo producto o servicio, indis- tintamente. Según se trate de uno u otro, este apartado del plan de empresa tendrá una de las siguientes formas: • En el caso de que la actividad de la empresa esté basada en el desarrollo, producción y posterior comercialización de un producto, se describirán en detalle las fases de desarrollo y producción.
  • © FUOC • P08/M2104/00604 123 Implantación, proyectos y empresas de software libre • En el caso de que la empresa se dedique a la prestación de un servicio sin ningún proceso productivo, se describirán en detalle los procedimientos para la prestación del servicio y las necesidades técnicas. Por supuesto, estos dos casos no son excluyentes y en un plan de empresa se pueden dar ambas. Por ejemplo, una empresa especializada en migración de sistemas a software libre que también ofrece servicios de formación en tecno- logías basadas en software libre a usuarios y a personal técnico. En general, la actividad empresarial que implica las fases de investigación, desarrollo y producción presenta una complejidad mucho mayor, y también mayores riesgos: • Fase￿de￿investigación￿y￿desarrollo. La descripción de la fase de investi- gación y desarrollo debe prestar especial atención a la estimación de la duración de la fase de investigación y desarrollo y de las necesidades de inversión en recursos materiales y humanos. Especialmente en sectores de alta tecnología, como es el caso del softwa- re libre, el plan de empresa debe evaluar la capacitación de los recursos humanos y el know-how necesarios para el éxito de las tareas de investiga- ción y desarrollo. Por otra parte, este apartado debe describir en detalle la distribución de funciones y responsabilidades, los riesgos inherentes a toda actividad de investigación y desarrollo, las potenciales sinergias entre proyectos, el proceso de innovación y mejora continua de los productos y cómo este proceso va a integrarse en el proceso de producción. D'altra banda, aquest apartat ha de descriure en detall la distribució de funcions i responsabilitats, els riscos inherents a tota activitat d'investigació i desen- volupament, les potencials sinergies entre projectes, el procés d'innovació i millora continuada dels productes, i la manera com s'integrarà aquest procés en el procés de producció. • Fase￿de￿producción. La descripción del proceso productivo debe descri- bir en primer lugar el ciclo operativo 48 , la localización de las instalaciones de producción, su coste y su accesibilidad. En segundo lugar, es necesario describir los locales, edificios y equipos necesarios para la producción o prestación de los servicios. Para cada uno de éstos se deben presentar las modalidades de financiación y adquisición49 , sus características, su dispo- nibilidad, su duración y su amortización anual. Se debe prestar especial atención a la gestión de la calidad, con la descripción de los estándares y certificaciones de calidad que se van a aplicar tanto a los procesos como a los resultados del proceso productivo. (48) Esto incluye la capacidad pro- ductiva en número de unidades y la producción esperada, así como el personal y el número de horas o turnos necesarios para la produc- ción. (49) Igualmente, se puede presentar los planes de expansión de las ins- talaciones y de adquisición de nue- vos equipos.
  • © FUOC • P08/M2104/00604 124 Implantación, proyectos y empresas de software libre Finalmente, se debe dar una visión estratégica del proceso productivo, por ejemplo en el caso de que se subcontrate la producción de algunos compo- nentes o una parte del proceso productivo 50 . De nuevo, la descripción del proceso productivo de software libre presenta una serie de diferencias respecto al desarrollo de software propietario, que deben ser explicadas adecuadamente en el plan de empresa, aún más cuando el lector puede no estar familiarizado con el software libre. Igualmente, es conveniente incidir en la calidad añadida que supone el software libre respecto al software propietario. En cualquier caso hay que recordar que siempre se deben presentar las ventajas y desventajas de las distintas alternativas y justificar cada una de las decisiones. 3.2.5. Organización interna y recursos humanos Este apartado del plan de empresa concreta la organización del equipo de trabajo necesario para el desarrollo del proyecto empresarial y los perfiles necesarios. (50) Por ejemplo, un editor de soft- ware libre podría subcontratar la producción del soporte de distri- bución y del embalaje de sus pro- gramas. Ampliando información En el apartado "Producción de software libre" de la tercera unidad se estudian en detalle las particularidades del proce- so de producción de software libre. En primer lugar, se debe incluir una descripción de las funciones y puestos de dirección clave, junto a los perfiles necesarios e incluso el nombre y currí- culo 51 de las personas que vayan a ocupar estos puestos en el caso de que ya estén decididas. En segundo lugar, se deben describir las diferentes categorías profesionales necesarias en la empresa, sus responsabilidades, las principales tareas que llevarán a cabo y la modalidad de contratación, entre otros. Es con- veniente indicar la remuneración correspondiente a cada tipo de trabajadores ya ocupen cargos directivos o no. La organización interna de la empresa se puede representar fácilmente me- diante un organigrama, por departamentos y áreas de actividad y con las per- sonas específicas, si existieran, en los puestos de dirección. Este apartado debe concluir con la descripción de la política general de la em- presa en el área de recursos humanos y decidir si es necesaria la creación de un departamento específico de recursos humanos o la gestión de éstos puede realizarse de forma distribuida en cada departamento. (51) Incluye su experiencia profesio- nal, su especialización y los princi- pales logros en su carrera. Este ti- po de información cumple una do- ble función: por un lado refuerza la confianza de los inversores po- tenciales y, por otro lado, permite descubrir las fortalezas y debilida- des del equipo gestor.
  • © FUOC • P08/M2104/00604 125 Implantación, proyectos y empresas de software libre La necesidad y la disponibilidad de personal cualificado en una determinada área y a un coste apropiado puede suponer en ocasiones una barrera de entrada importante, como puede ser el caso de especialistas en software libre 52 . Además, una empresa que base su modelo de negocio en software libre puede precisar de puestos y responsabilidades adaptados a sus particularidades. Por ejemplo, junto a los puestos clásicos de director técnico o director comercial, se pueden encontrar roles como director de comunidad, responsable de la ges- tión de las relaciones con los desarrolladores y usuarios de software libre o di- rector de proyectos en cooperación, responsable de la gestión y coordinación de proyectos que se lleven a cabo en colaboración con otras empresas, centros de investigación o universidades. 3.2.6. Estudio de mercado El estudio de mercado es una parte fundamental de un plan de empresa, y por tanto una de las claves de su éxito. Un buen estudio de mercado va a permitir evaluar correctamente la viabilidad técnica y económica del proyecto empresarial y a identificar los potenciales clientes y competidores, de manera que se pueda definir la estrategia adecuada para vender los productos o servicios objeto del plan de empresa. En la elaboración de un plan de empresa es conveniente realizar el estudio de mercado en primer lugar, o al menos en una primera aproximación, ya que sus resultados pueden afectar a diferentes partes del plan de empresa. Así, el análisis de mercado debe proporcionar información sobre los aspectos siguientes: • Situación￿actual￿del￿mercado. En primer lugar, es necesario segmentar el mercado de acuerdo a las características más relevantes en el plan de empresa y determinar su volumen, así como su evolución histórica. Igual- mente, hay que determinar el proceso de decisión en el mercado y el com- portamiento de los clientes, en particular su reacción ante la introducción de nuevos productos o servicios. En segundo lugar, hay que evaluar las posibles necesidades que podría ge- nerar la introducción de los productos o servicios propuestos en el plan de empresa. Esto depende en buena medida de si el producto o servicio aporta algo nuevo y de la capacidad de influir en los hábitos de los clientes. • Previsiones￿sobre￿el￿crecimiento￿del￿mercado. Una vez se conoce el es- tado actual del mercado hay que ser capaz de realizar previsiones sobre su evolución futura. ¿Se trata de un mercado en crecimiento, estable o en (52) Por ejemplo, en el momento de la edición de estos materiales, si bien el software libre es ya co- nocido y las tecnologías y solucio- nes basadas en él bastante popu- lares, es difícil encontrar profesio- nales que hayan participado acti- vamente en proyectos de software libre, ya sea como empleados en una empresa o por propia iniciati- va.
  • © FUOC • P08/M2104/00604 126 Implantación, proyectos y empresas de software libre decadencia? ¿Cuál es el nivel de fragmentación del mercado? ¿Se está pro- duciendo un proceso de concentración? De nuevo, hay que tener en cuenta la influencia que los nuevos produc- tos o servicios podrían tener en el mercado. Por ejemplo, la introducción de soluciones basadas en software libre puede efectivamente cambiar el mercado, al propiciar la formación de un nuevo sector especializado en software libre. • Identificación￿y￿clasificación￿de￿los￿clientes. Uno de los objetivos fun- damentales de un análisis de mercado es descubrir quiénes serán los clien- tes potenciales de los productos y servicios propuestos. La labor de clasi- ficar los diferentes tipos de clientes de acuerdo a ciertas características co- munes es también muy importante, ya que permite definir diferentes es- trategias para cada uno de ellos. Por ejemplo, una empresa que ofrezca la implantación de sistemas de software libre para empresas se presentará de manera distinta a sus clientes según éste sea una empresa familiar o una gran corporación. Hay que tener en cuenta también que un mismo pro- ducto o servicio puede ofrecerse a clientes a priori diferentes. La flexibili- dad e interoperabilidad del software libre favorece esto último. Por otra parte, se debe evaluar la recepción del producto o servicio por parte de cada tipo de cliente. Siguiendo con el ejemplo anterior de una empresa especializada en la implantación de sistemas de software libre, una gran empresa que cuente con personal técnico dedicado puede ser más reticente a la adopción del software libre, en parte por el miedo al cambio, mientras que una empresa familiar puede ser más receptiva. Finalmente, en el caso de que la futura empresa cuente ya con una car- tera de clientes, o de que existan clientes que hayan mostrado su interés en sus productos o servicios, es conveniente recoger esto en el estudio de mercado. • Análisis￿de￿la￿competencia￿y￿de￿sus￿productos. El estudio de mercado debe dar cuenta de los competidores de la futura empresa, así como iden- tificar tanto sus fortalezas y debilidades como las de los productos o servi- cios que ofrecen. Se debe proporcionar información sobre las características de sus produc- tos y servicios, incluyendo su precio y calidad, así como su cuota de mer- cado y su estrategia comercial. Es muy importante identificar los líderes en el mercado de cada uno de los productos o servicios previstos en el plan de empresa. Igualmente, no se deben descuidar los potenciales competidores en el fu- turo, es decir, qué empresas que todavía no están en el mercado podrían entrar en él; ni tampoco los de otras regiones geográficas. En el contexto actual y especialmente en los sectores relacionados con las tecnologías de la información y las comunicaciones, como el software libre, la compe- tencia tiende a ser global y muchas empresas pueden ofrecer sus servicios directa o indirectamente en cualquier lugar.
  • © FUOC • P08/M2104/00604 127 Implantación, proyectos y empresas de software libre • Análisis￿de￿las￿barreras￿de￿entrada. Las barreras de entrada son los obs- táculos que toda empresa se encuentra al entrar en un nuevo mercado. Por ejemplo, la necesidad de una fuerte inversión en el caso de empresas de nueva creación o la ausencia de una marca establecida. Por ejemplo, el software libre se encuentra a menudo con la falta de calidad percibida, frente a empresas y soluciones de software propietario establecidas en el mercado. Claro que, de la misma manera, se pueden estudiar qué barreras de entra- da se pueden favorecer una vez instalados en el mercado, para mantener alejada la competencia. • Influencia￿de￿las￿administraciones￿públicas. El estudio de mercado de- be tener en cuenta el modo en que las administraciones públicas, loca- les, regionales, nacionales o internacionales pueden afectar al mercado y, en consecuencia, a la viabilidad del plan de empresa. Así, las administra- ciones pueden actuar como reguladoras del mercado, pero también como proveedores y como clientes. Esto es particularmente cierto en el caso del software libre, que como se ha visto a lo largo de la asignatura es motivo de interés de múltiples ad- ministraciones, como la Junta de Extremadura o el Gobierno de Brasil. La realización de un estudio de mercado se debe planificar cuidadosamente y atraviesa diferentes fases, que se resumen en las siguientes: – Recogida de información general, donde se obtiene un gran volumen de datos sobre el mercado objeto de estudio. – Análisis de la información obtenida. – Búsqueda selectiva de información, donde se obtiene la información ausente y necesaria para completar el estudio de mercado, que se habrá identificado tras el análisis previo. Para llevar a cabo la elaboración de un estudio de mercado se necesita una gran cantidad de información, que no siempre es de fácil acceso. Existen numerosos organismos y fuentes de información, tanto generales como especializadas en ciertas regiones o sectores: administraciones e institutos de estadística nacionales, administraciones regionales y locales, organis- mos privados como las cámaras de comercio o las asociaciones de empre- sas y revistas y publicaciones especializadas. Un buen estudio de mercado debe concluir con un análisis estratégico 53 que relacione los resultados del propio estudio con la descripción del ne- gocio y los recursos previstos y que muestre el potencial del plan de em- presa.
  • © FUOC • P08/M2104/00604 128 Implantación, proyectos y empresas de software libre (53) A su vez, este análisis puede apoyarse en la utilización de he- rramientas estratégicas como el análisis DAFO (http://es.wikipedia.org/wiki/ An%C3%A1lisis_DAFO) o de las 5 fuerzas de Porter (http://es.wikipedia.org/wiki/ An%C3%A1lisis_Porter_de_las_cinco_fuerzas). 3.2.7. Plan de marketing El objetivo del plan de marketing es la definición de las estategias co- merciales que permitan alcanzar el volumen de facturación previsto en el análisis económico-financiero, que se verá en detalle en el apartado siguiente. Por tanto, el plan de marketing detalla las acciones a llevar a cabo para explo- tar el modelo y la oportunidad de negocio descritos en el plan de empresa y aprovechar sus ventajas competitivas. De este modo, el plan de marketing debe recoger los siguientes aspectos: • Estrategia￿comercial￿global. La estrategia global debe definir de qué ma- nera la parte comercial se integra en el proyecto empresarial. Se debe ex- plicar cómo se van a identificar los clientes y cómo se contactará con ellos, cuáles son las motivaciones de los clientes al interesarse o decidirse por los productos o servicios ofrecidos y, en consecuencia, las características de los productos o servicios que se van a destacar para generar ventas, por ejemplo el precio, la calidad, la garantía y el soporte técnico, etc. El caso del software libre es bastante ilustrativo, ya que el principal recla- mo para los potenciales clientes es la reducción de costes, y no tanto la calidad, que a menudo es superior a la del software propietario. En cam- bio, el cliente suele identificar los precios elevados del software propietario con una calidad superior, y el software libre, que resulta más económico, con una calidad inferior. Por ello, a la hora de realizar un plan de empresa basado en un modelo de negocio de software libre es esencial destacar la calidad superior 54 del software libre. • Estrategia￿de￿ventas: define cuáles son los objetivos de ventas a corto y largo plazo así como en qué sectores del mercado se van a introducir los productos o servicios ofrecidos en una primera fase y en el futuro. En cual- quier caso, se deben justificar adecuadamente las decisiones, apoyándose en los resultados del estudio de mercado. (54) Por ejemplo, poniendo en pri- mer plano la interoperabilidad y la flexibilidad y la constante revisión y mejoras a las que está sometido el software libre. • Estrategia￿de￿precios: determina en primer lugar los precios con los que se van a comercializar los productos y servicios ofrecidos, comparándolos, si es posible, con los de los competidores, con una estimación del margen bruto de beneficios y una evaluación para determinar si este margen es suficiente para soportar toda la actividad empresarial 55 . (55) Igualmente, es recomendable comparar los márgenes propios con los de la competencia, en el caso de que se disponga de tal in- formación.
  • © FUOC • P08/M2104/00604 129 Implantación, proyectos y empresas de software libre Es muy importante justificar la política de precios, sobre todo en compara- ción con la de los competidores. En el caso de que el precio de los produc- tos o servicios ofertados sea superior a los de la competencia, se debe expli- car en términos de novedad y calidad, prestaciones y garantías superiores. En el caso de que el precio sea inferior, se debe justificar cómo se mantie- ne la rentabilidad, por ejemplo gracias a una mayor eficiencia y menores costes de producción. De nuevo, es muy importante explicar las causas del bajo coste del software libre y los beneficios que lleva aparejados. Finalmente, hay que tener en cuenta que la estrategia de precios debe ser la óptima, es decir, aquella que maximice el margen de beneficios y por tanto la rentabilidad. En ocasiones, un precio más elevado, a pesar de reducir en parte las ventas, puede acarrear mayores beneficios. • Política￿de￿ventas: recoge la composición, forma de contratación y perfil del equipo comercial o de ventas, incluyendo comerciales y representan- tes, en el momento de puesta en marcha de la empresa y su evolución a medio y largo plazo. Esto incluye la política de márgenes comerciales, las medidas de promoción que se van a ofrecer a representantes, comerciales y también distribuidores autorizados. Forman también parte de la política de ventas: la estimación de las ventas de cada comecial y representante, los incentivos, los períodos de cobro acordados a los clientes, las promociones especiales como descuentos, an- ticipos, rappels, etc. • Promoción￿y￿publicidad: debe describir las medidas que se van a poner en práctica para atraer la atención de clientes potenciales hacia los pro- ductos o servicios ofrecidos. Estas medidas incluyen pasar por buzoneos electrónicos, participación en ferias y eventos comerciales, publicidad en sitios web, etc. Finalmente se debe cuantificar el coste de la promoción y su retorno, en consultas de clientes y ventas cerradas. • Servicio￿posventa￿y￿garantías: debe describir el servicio posventa y las garantías que se ofrecen a los productos o servicios ofrecidos, cuando sea aplicable. Es decir, qué tipo de servicio y garantía se ofrece, su duración temporal, su precio en el caso de que sea optativa y sus costes para la em- presa. En el caso del software libre, una parte del servicio posventa está propor- cionado indirectamente por la comunidad de desarrolladores y usuarios, que en proyectos de éxito mejoran constantemente el producto. El plan de empresa basado en software libre debe tener esto en cuenta y presentarlo como una ventaja, pero nunca como el único soporte añadido. Hay que tener en cuenta que la inmensa mayoría de los clientes desean que el ser- vicio posventa esté incluido y garantizado en las condiciones de la venta.
  • © FUOC • P08/M2104/00604 130 Implantación, proyectos y empresas de software libre Por último, se debe valorar también la importancia del servicio posventa y de las garantías ofrecidas en la decisión final del cliente, y comparar el servicio propio con el proporcionado por los competidores. • Política￿de￿distribución: La política de distribución debe describir los ca- nales de distribución que se van a utilizar y las políticas de descuentos, comisiones y márgenes asignados a cada uno de estos canales. En los modelos de negocio de software libre encontramos con frecuencia la existencia de programas para empresas asociadas 56 bajo distintas formas: integradores de sistemas, vendedores de software, etc., y a las que se les ofrece comisiones y se les facilitan servicios y asistencia dedicada y acceso a canales de promoción. Por otra parte, como se ha comentado anteriormente, los productos y ser- vicios de software libre pueden ofrecerse a menudo sin problemas en el mercado global, por lo que el plan de marketing debe estudiar esta posi- bilidad y las particularidades que presentaría, incluyendo el efecto de las leyes internacionales en la actividad de la empresa, la gestión de los cobros en el extranjero, etc. 3.2.8. Análisis económico-finaciero El análisis o estudio económico-financiero es también uno de los ele- mentos básicos de todo plan de empresa, ya que su objetivo es evaluar la viabilidad y el potencial económico del proyecto empresarial, detectar las necesidades de inversión para su puesta en marcha, identificar los recursos disponibles inicialmente y presentar las distintas posibilidades de financiación. Contrariamente a lo que podría parecer, el análisis económico-finaciero es una de las partes más creativas de la elaboración de un plan de empresa. Los estados finacieros o aspectos fundamentales que debe cubrir el análisis económico-finaciero son los siguientes: (56) Por ejemplo, el programa de asociados del ERP basado en software libre Openbravo, que podéis consultar en http:// www.openbravo.com/partners/ join-openbravo/details/. • Estado de la tesorería durante el primer año desglosada por meses, a fin de reflejar los efectos de la estacionalidad 57 . • Análisis del fondo de maniobra, que permite conocer la liquidez patrimo- nial de la empresa. • Cálculo del punto de equilibrio y alternativas en el caso de que el volumen de ventas objetivo no se alcanzara. (57) Incluso planes de empresa con un fuerte componente tecnológi- co, como los basados en softwa- re libre, se ven afectados por la es- tacionalidad de la economía, por ejemplo durante las vacaciones de verano.
  • © FUOC • P08/M2104/00604 131 Implantación, proyectos y empresas de software libre • Necesidades y alternativas de financiación, elegiendo las más rentables y aportando los elementos que justifiquen la decisión. • Balances anuales a cinco años vista, con el primer año desglosado por me- ses. • Origen y aplicación de los fondos, que permite pronosticar situaciones de riesgo para la empresa y evaluar la procedencia y utilización de fondos a largo plazo. Fondo de maniobra El fondo de maniobra mide el equilibrio patrimonial de una entidad, ya que acredita la existencia de activos líquidos en mayor cuantía que las deudas con vencimiento a corto plazo. Podéis obtener más información en http://www.innovaceei.com/es/knowledgeba- se/index.asp?faqsRecid=385&faqRecid=385&show=4460. Es conveniente realizar un análisis conjunto de estos estados financieros y ob- tener unas conclusiones que aporten información sobre el proyecto empresa- rial en su conjunto: la cantidad de capital necesario y cuándo será necesario, y la deuda necesaria y cuándo se debe pagar esta deuda, entre otros. Igualmente se debe explicar la rentabilidad esperada de la inversión y cuándo se recuperará esa inversión. Como se comentó anteriormente, hay que evitar caer en la tentación de pre- sentar un análisis económico-finaciero demasiado optimista para ganarse la confianza de los inversores, ya que tarde o temprano se volverá contra la pro- pia empresa y pondrá en entredicho su viabilidad y credibilidad. 3.2.9. Forma legal Si el objetivo último del plan de empresa es efectivamente la creación de una nueva empresa 58 , se debe elegir la forma legal con la que ésta se va a constituir, su régimen fiscal y sus socios fundadores. Del mismo modo, se debe recoger el nombre de todos los socios e inversores y su participación en la nueva so- ciedad. Es conveniente detallar paso a paso todos los trámites necesarios para cons- tituir la nueva empresa, así como su coste y el tiempo necesario para su eje- cución. Se debe también especificar si se va a recurrir a servicios de asesoría externa especializada y su coste. (58) En el caso de que se tratara de un plan de negocio para una em- presa ya constituida, este apartado describiría la naturaleza jurídica de ésta y las posibles modificaciones que la implementación del plan de negocio podría llevar consigo.
  • © FUOC • P08/M2104/00604 132 Implantación, proyectos y empresas de software libre 3.2.10. Gestión de riesgos Todo proyecto empresarial, ya se trate de la creación de una nueva empresa o de una nueva línea de negocio, implica numerosos riesgos que en ocasio- nes son ineludibles. Por ello, el plan de empresa debe incluir una descripción completa de los riesgos y de sus consecuencias. Los riesgos pueden clasificarse según sean internos, con origen en la propia empresa, o externos, y según al área funcional que afecten: técnica, comercial, etc. Por ejemplo, riesgos internos pueden ser la existencia de retrasos en la produc- ción o falta de personal cualificado, mientras que riesgos externos puede ser una nueva regulación del mercado, que reduzca en parte la rentabilidad o la aparición de nuevas tecnologias que dejen obsoletos los productos o servicios ofrecidos. Ampliando información En el apartado "Gestión de riesgos" de la primera unidad podréis encontrar una intro- ducción general a este tema. Para cada riesgo se debe definir un plan de contingencia, lo que incluye una serie de acciones de prevención 59 , es decir, para evitar que el riesgo llegue a realizarse, y una serie de acciones de mitigación o remedio 60 , qa adoptar en el caso de que el riesgo se realice. Hay que tener en cuenta que algunos riesgos pueden provocar efectos negati- vos, pero también positivos. Por ejemplo, cambios en el marco legal o político que pueden afectar al modelo de negocio, pero al mismo tiempo dar lugar a nuevas oportunidades de negocio. La correcta identificación y evaluación de los riesgos en un proyecto empresa- rial y la preparación de planes de contingencia adecuados, antes que denotar debilidades del proyecto, destacan las habilidades de gestión y de previsión de los promotores y aumentan su credibilidad. 3.2.11. Resumen y evaluación El último apartado del plan de empresa debe resumir los puntos fuertes y débiles del proyecto empresarial, las ventajas y oportunidades que ofrece y las principales amenazas y riesgos. El resumen es la última oportunidad para convencer a un inversor potencial, así que se debe ser muy convincente y aprovecharlo para reforzar los argumen- tos a favor del proyecto empresarial y en los que creen sus promotores. (59) Por ejemplo, para prevenir la aparición de nuevas tecnologías que pudieran dejar obsoletos los productos o servicios previstos en el plan de empresa se debería po- ner en práctica una vigilancia tec- nológica activa y, eventualmente, colaborar con empresas u organi- zaciones que trabajen en la misma área. (60) Por ejemplo, se podrían asig- nar recursos humanos y materiales provenientes de otros departamen- tos a fin de recuperar el retraso en la producción.
  • © FUOC • P08/M2104/00604 133 Implantación, proyectos y empresas de software libre Sin embargo, puede darse la posibilidad de que tras la elaboración del plan de empresa los propios promotores del proyecto descubran que éste no sea tan rentable como se esperaba, o incluso completamente inviable. Esto muestra la utilidad del plan de empresa como herramienta para la identificación de las mejores oportunidades de negocio. 3.2.12. Plan de empresa y software libre La elaboración de un plan de empresa basado en software libre no presenta grandes diferencias respecto a los planes de empresa de otros sectores y algu- nas de sus particularidades ya se han presentado a lo largo de los apartado anteriores. En general, hay que recordar que un plan de empresa puede estar dirigido a diferentes tipos de lectores: asesores, inversores, técnicos, banqueros. Por ello se debe emplear un lenguaje comprensible por todos ellos y evitar la utilización de un vocabulario demasiado técnico. Cuando la utilización de estos términos sea inevitable, es recomendable explicar bien cada uno de los conceptos en un lenguaje accesible. Un inversor nunca invertirá en algo que no comprende del todo. Igualmente, hay que prestar atención a explicar las particularidades del soft- ware libre, haciendo hincapié en las diferencias respecto al software propieta- rio y sus principales ventajas. No hay que dudar en recurrir a ejemplos reales y casos de éxito que refuercen los argumentos presentados en el plan de em- presa. Por otra parte, si bien el software libre comienza a tener un papel cada vez más relevante en los medios y en la sociedad gracias al compromiso de la comunidad de software libre, de empresas y de administraciones públicas, su naturaleza y sus implicaciones económicas no son tan conocidas. De nuevo, hay que prestar mucho cuidado a explicar correctamente los mo- delos de negocio basados en software libre y estar preparado para responder e incluso anticipar las preguntas más frecuentes. Por ejemplo, ¿cómo se puede invertir y ganar dinero en algo que cualquiera puede copiar? 3.3. Producción de software libre Buena parte de los modelos de negocio presentados en el primer apartado dependen, en mayor o menor medida, del desarrollo de software libre. Uno de los problemas a la hora de hablar de proyectos de software libre es que tan solo los proyectos exitosos tienen repercusión en la comunidad y sólo los muy exitosos llegan a los medios no especializados.
  • © FUOC • P08/M2104/00604 134 Implantación, proyectos y empresas de software libre Sin embargo, antes de abordar la producción de software libre hay que recordar que la inmensa mayoría de proyectos de software libre son un fracaso, por unas razones o por otras. Puede deberse simplemente a que el proyecto no consigue producir un software de calidad y competitivo, o bien porque no consigue atraer la atención de la comunidad de desarrolladores y usuarios. Por supuesto, y como se ha visto en los materiales de la asignatura, no hay que olvidar que un proyecto de software libre debe tratarse como un proyecto de software, y en último lugar, simplemente como un proyecto de ingeniería. Por ello, todo proyecto de software libre presenta en primer lugar los mismos riesgos y problemas que cualquier otro proyecto. Sin embargo, y dada la naturaleza libre de este tipo de proyectos, hay también otras fortalezas y debilidades que conviene conocer. Por el carácter aparen- temente no profesional de muchos proyectos de desarrollo de software libre puede parecer que la ejecución de éstos, respecto a la de los proyectos de desa- rrollo de software tradicionales, sea más sencilla. Nada más lejos de la realidad. El objetivo de este apartado es presentar las particularidades de los proyectos de desarrollo de software libre respecto al desarrollo de software propietario y mostrar una serie de buenas prácticas que faciliten su éxito. Estas prácticas se corresponden con las principales áreas y elementos necesarios para poner en marcha y ejecutar un proyecto de software libre, que son las siguientes: • Creación y presentación del proyecto • Infraestructura necesaria • Organización de la comunidad • Desarrollo • Releasing y packaging • Elección de licencias Por supuesto, no todos estos pasos son obligatorios. Como se ha visto en los modelos de negocio, una empresa dedicada al software libre puede ser la ini- ciadora del proyecto, o bien, en la mayoría de los casos, unirse a un proyecto ya existente. Esta última opción es con frecuencia la más recomendable y, de hecho, dada la naturaleza del software libre, no excluye la posibilidad de que a partir de un proyecto existente se cree uno nuevo con la identidad de la empresa o la organización interesada en dirigir su desarrollo.
  • © FUOC • P08/M2104/00604 135 Implantación, proyectos y empresas de software libre 3.3.1. Creación y presentación del proyecto Este apartado se ocupa fundamentalmente de los pasos necesarios para crear un nuevo proyecto de software libre y presentarlo a la comunidad. Así, el primer paso antes de crear un nuevo proyecto es descubrir si existe al- gún proyecto que realice al menos en parte lo que se pretende. Si hay un pro- yecto similar de software libre al que se puede contribuir, o que se puede rea- provechar para poner en marcha el nuevo proyecto, es conveniente ponerse en contacto con sus responsables para explorar las posibilidades de colabora- ción y sus planes futuros. Buscadores genéricos Los buscadores genéricos son la primera etapa para descubrir proyectos existentes, así como los sitios de noticias, los directorios y las forjas públicas como http://freshmeat.net, http://directory.fsf.org y http://www.sourceforge.net. Si se ha decidido crear un nuevo proyecto, lo primero que hay que hacer es elegir un nombre que lo identifique en la comunidad. Como regla general, un buen nombre debe dar una idea de qué hace el software, o al menos de su campo de aplicación, y debe ser fácil de recordar. Para bien o para mal, el inglés es la lengua oficial de facto en Internet. Por ello, si el proyecto busca tener un impacto global, y así debería ser en la mayoría de los casos, es conveniente que el nombre tenga cierto significado en inglés, o bien que sea neutro 61 . Por otra parte, se debe prestar atención a los aspectos legales, de manera que el nombre no entre en conflicto con marcas registradas y que los potenciales dominios de alto nivel 62 en Internet asociados estén disponibles. De la misma manera que se ha visto en el apartado dedicado a la creación de un plan de empresa, todo proyecto debería contar con una definición clara de su misión, que atraiga la atención de usuarios y desarrolladores y les permita decidir si están interesados en el proyecto, o no. Junto a la misión, es igualmente importante identificar inequívocamente el proyecto como software libre, lo cual implica hacer una referencia clara a soft- ware libre (free software) o software de código abierto (open-source software). Otros elementos importantes a la hora de presentar un proyecto de software libre son: (61) Es decir, que sea un nombre co- mún a varias lenguas, como Apa- che, o que no se asocie a otra len- gua mayoritaria, como por ejem- plo Ubuntu. (62) Es decir, los dominios .com, .net y .org. • Lista￿de￿funcionalidades￿previstas 63 ￿y￿requisitos￿actuales. Redactada de una manera sencilla, es decir, sin tecnicismos. Es, en cierto modo, un resu- men detallado de lo que hace el software, que permita a los usuarios saber fácilmente si se trata de las funcionalidades que buscan. (63) Se pueden indicar con una mención "en progreso" o "en desa- rrollo", idealmente con la fecha o la versión en que estarán disponi- bles.
  • © FUOC • P08/M2104/00604 136 Implantación, proyectos y empresas de software libre De igual modo, los requisitos deben ser fáciles de entender, de manera que el usuario sepa si puede instalar y utilizar la aplicación en su sistema. • Estado￿de￿desarrollo. En la comunidad de software libre los usuarios sue- len estar muy interesados en saber cómo avanza el desarrollo del proyec- to, tanto si se trata de un nuevo proyecto como de uno ya maduro. Para ello deben explicarse los objetivos del proyecto a corto y largo plazo, las funcionalidades en las que se está trabajando actualmente y que estarán disponibles en futuras releases, etc. • Descargas￿disponibles. El código fuente debe poder descargarse siempre en formatos estándar, de una manera sencilla, que no suponga ninguna complicación para el usuario 64 . El proceso de instalación también debe ser sencillo y, sobre todo, de acuer- do a los estándares desde el principio del proyecto. Igualmente, en un pri- mer momento no es necesario facilitar paquetes binarios o ejecutables, a menos que el proceso de compilación sea muy complejo. • Repositorio￿de￿desarrollo. Los potenciales desarrolladores, al contrario que los usuarios, están más interesados en acceder al repositorio de trabajo, donde se puede seguir la evolución del proyecto día a día y participar en ella, ya sea añadiendo nuevas funcionalidades o corrigiendo errores. Para ello es conveniente que todos puedan acceder a la lectura del repositorio, mediante un acceso anónimo. (64) Es conveniente, por ejemplo, evitar procesos de registro de usuarios para acceder a la sección de descargas. • Seguimiento￿de￿errores. Al igual que el repositorio, la base de datos de seguimiento de errores 65 debe estar también abierta a todos. Paradójica- mente, un proyecto es mejor cuantos más errores contiene su base datos, ya que esto implica un mayor número usuarios y una mayor participación de los usuarios en el proyecto. Al inicio del proyecto, el número de errores será muy bajo. Una buena práctica es registrar en la base de datos los errores resueltos internamente por el equipo que pone en marcha el proyecto. • Canales￿de￿comunicación. Uno de los objetivos de todo proyecto de soft- ware libre es crear una comunidad alrededor de él y, para que dicha co- munidad se organice, es necesario facilitar los canales de comunicación adecuados. Esto incluye listas de correo, canales de IRC, foros, etc. En una primera fase del proyecto es conveniente no diversificar ni espe- cializar en exceso los canales de comunicación. Un único foro o lista de distribución para usuarios y desarrolladores puede ser suficiente y favore- cer las interacciones entre ellos. • Documentación￿para￿usuarios￿y￿desarrolladores. La documentación es esencial en todo proyecto de software libre, tanto para los usuarios como para los desarrolladores. (65) Con frecuencia se hace referen- cia a los términos bug tracker o bug database en inglés.
  • © FUOC • P08/M2104/00604 137 Implantación, proyectos y empresas de software libre Una buena documentación para el usuario debe explicar a éste cómo ins- talar el software y cómo utilizar sus funciones. Se le puede facilitar tam- bién un pequeño tutorial, que le enseñe a realizar las tareas más frecuentes paso a paso. Un excelente complemento de la documentación es el man- tenimiento de una sección de preguntas frecuentes o FAQ. La documentación para desarrolladores debe incluir la información de contacto de los principales desarrolladores del proyecto, las instrucciones para enviar informes de errores y parches, así como una presentación so- bre la organización del desarrollo y la toma de decisiones entre los desa- rrolladores. Todos estos elementos se verán en detalle en los apartados siguientes. Para concluir este apartado cabe destacar que la apariencia –es decir, cómo la comunidad de software libre percibe el proyecto– tiene un papel bastante importante en el éxito o el fracaso de un proyecto de software libre. Muchos desarrolladores no prestan suficiente atención a esta tarea de comu- nicación y relaciones públicas, la cual, sin embargo, es un elemento indispen- sable en prácticamente todos los proyectos de software libre de éxito. Para ello hay que definir claramente cuales son los objetivos del nuevo soft- ware, que normalmente se pueden resumir en: • Definir￿claramente￿qué￿hace￿el￿software: sus funcionalidades principa- les, el estado actual de desarrollo y los planes de futuro, además de su po- sicionamiento respecto a las soluciones y los proyectos ya existentes. • Dar￿a￿conocer￿el￿software: hacerlo llegar a la comunidad o al mercado de usuarios y desarrolladores potencialmente interesados. • Potenciar￿el￿uso￿del￿software: que los usuarios y los desarrolladores po- tenciales sepan utilizar el nuevo software y lo adopten frente a las solucio- nes alternativas. • Involucrar￿nuevos￿desarrolladores￿en￿el￿proyecto: que éstos contribu- yan al desarrollo del proyecto mediante la implementación de nuevas fun- cionalidades y que aporten sus puntos de vista sobre la dirección que de- bería tomar el proyecto en el futuro. Los dos últimos objetivos, conseguir muchos usuarios y muchos desarrollado- res, son a menudo los más importantes. Sin embargo, es necesario poner en práctica una estrategia para los usuarios y otra diferente para los desarrollado- res, los cuales, aun perteneciendo a la misma comunidad de software libre, representan audiencias muy distintas.
  • © FUOC • P08/M2104/00604 138 Implantación, proyectos y empresas de software libre Se debe definir claramente el mensaje que quiere hacerse llegar a cada uno de ellos y estructurarlo con una complejidad progresiva, de modo que el nivel de detalle ofrecido se corresponda con el esfuerzo requerido por parte del lector. Por ejemplo, no tiene sentido saturar al usuario con la arquitectura del soft- ware, ni tampoco adentrar a los desarrolladores en detalles técnicos sin antes dar una visión adecuada de la arquitectura. Finalmente, este mensaje debe ser fácilmente accesible y puede hacerse llegar a sus destinatarios mediante anuncios en foros o comunidades relacionadas, en el sitio web del proyecto e incluso en la documentación, entre otros. 3.3.2. Infraestructura Cualquier proyecto de software libre necesita una serie de herramientas que permitan gestionar la información que se genera en el día a día del proyecto, desde el código desarrollado hasta las comunicaciones entre sus miembros. Algunas de estas herramientas ya se han introducido en el apartado anterior, pues son esenciales para poner en marcha el proyecto: • Sitio￿web Proporciona una fuente centralizada de información sobre el proyecto y da acceso a otras herramientas de gestión especializadas. • Listas￿de￿correo Es uno de los canales de comunicación utilizados con más frecuencia en los proyectos de software libre. Los intercambios de mensajes suelen que- dar archivados y se utilizan como referencia y base de conocimiento del proyecto. • Sistema￿de￿control￿de￿versiones Permite que los desarrolladores controlen la creación y la gestión de códi- go, volviendo a versiones anteriores y uniendo diferentes versiones. Gra- cias al sistema de control de versiones, cualquiera puede visualizar el esta- do actual del código, así como su evolución en el tiempo. • Sistema￿de￿seguimiento￿de￿errores Permite que los desarrolladores realicen un seguimiento de las funcionali- dades y los errores en los que está trabajando cada uno, se coordinen entre ellos y planifiquen las próximas releases. Si bien el seguimiento de errores es su función principal, la base de datos puede utilizarse igualmente para realizar el seguimiento de cualquier tarea del proyecto, como las nuevas funcionalidades.
  • © FUOC • P08/M2104/00604 139 Implantación, proyectos y empresas de software libre Gracias al sistema de seguimiento de errores, cualquiera puede saber si un determinado error ha sido solucionado o si alguien está trabajando en él. Junto al sistema de control de versiones, permite conocer el dinamismo y la actividad registrada del proyecto. • Chat￿o￿canal￿de￿conversación Proporciona un canal de comunicación donde resolver dudas y problemas rápidamente. Las conversaciones no se suelen archivar, por lo que es acon- sejable que las discusiones más complejas tengan lugar en listas de correo. Cada una de estas herramientas responde a unas necesidades concretas, prin- cipalmente de comunicación y de gestión de la información. La experiencia y las características de la comunidad de usuarios y desarrolladores alrededor del proyecto van a dictar la configuración y el uso de estas herramientas. No obs- tante, vale la pena comentar algunos aspectos que pueden resultar de utilidad para la mayoría de proyectos de software libre. Las listas de correo son un elemento esencial de todo proyecto de software libre, por lo que hay prestar especial atención a su gestión y uso. Es práctica- mente obligatorio disponer de un sistema gestor de listas de distribución, cuya configuración y mantenimiento pueden resultar complicados en un principio. Las funcionalidades y las opciones principales de un sistema gestor de listas de distribución son las siguientes: • Suscripción mediante correo electrónico y mediante una interfaz web • Suscripción en modo digest o normal 66 • Moderación • Interfaz de administración • Configuración de las cabeceras de los mensajes • Gestión y consulta de archivos Por otra parte, las listas de correo se pueden integrar con otras herramientas tales como el sistema de control de versiones o el sistema de seguimiento de errores para notificar, por ejemplo, cambios en el código fuente o modifica- ciones en el estado de errores y tareas en curso. Igualmente, el sistema de control de versiones es un elemento indispensable para cualquier proyecto de software libre que aspire a articular una comunidad de desarrolladores. El funcionamiento de casi todos los sistemas de control de versiones se basa en la existencia de una copia remota, compartida por todos los desarrolladores y de la que se pueden consultar todas las versiones. Cada Recursos web Entre los sistemas más populares están Mail- man (http://www.list.org), Smartlist (http:// www.procmail.org), Ecar- tis (http://www.ecartisorg), Listproc (http:// listproc.sourceforge.net) o Ezmlm (http://cr.yp.to/ exmlm.html). (66) En el modo digest se recibe una compilación de todos los mensajes periódicamente, normalmente ca- da mes o cada semana, mientras que en el modo normal los mensa- jes se reciben inmediatamente.
  • © FUOC • P08/M2104/00604 140 Implantación, proyectos y empresas de software libre desarrollador dispone de una copia local de esa copia remota, sobre la que trabaja. Puntualmente, cada desarrollador envía sus modificaciones a la copia remota, compartiéndolas con el resto. Las funcionalidades principales de un sistema de control de versiones son: • Commit: integrar los cambios de la copia local en la copia remota, los cuales quedan así registrados en la base de datos de control de versiones. • Update: integrar los cambios de los demás desarrolladores en la copia local. • Checkout: obtener una copia local a partir de la copia remota. Vale la pena destacar que, dentro del proyecto, todo documento o archivo editado puede y debe ser objeto de un control de versiones, por lo que éste no se debería limitar a los archivos de código fuente. La utilización de un sistema de control de versiones puede resultar muy práctica para editar y compartir documentación o informes técnicos y, en general, para cualquier documento que haya sido creado y mantenido en colaboración. Como se ha comentado anteriormente, el sistema de seguimiento de errores permite realizar muchas otras funciones, además de la que indica su nombre. Esto incluye el seguimiento de cualquier tipo de tarea, como la implementa- ción de funcionalidades nuevas, la preparación de releases o el soporte a los usuarios. El ciclo de vida de un error suele ser el siguiente: • Notificación￿del￿error: Todo error incluye al menos un resumen y una descripción inicial que contienen, a ser posible, los elementos necesarios para reproducir el error. La mayoría de sistemas de seguimiento de errores permite configurar campos específicos. No hay que olvidar que los errores pueden venir tanto de la comunidad de usuarios como de la de desarro- lladores. Una vez archivado, el error queda en estado abierto y no está asignado a nadie. Durante ese tiempo, la gente que acceda a la base de datos puede leer la descripción del error y, eventualmente, pedir más información al usuario o al desarrollador que lo ha notificado. • Reproducción￿del￿error: Siguiendo las indicaciones de la descripción del error, alguien consigue reproducirlo, por lo que éste queda validado. Es decir, se puede decir que el error es auténtico. • Diagnóstico￿del￿error: Durante las fases anteriores puede ocurrir que un desarrollador se haga responsable de la resolución del error, o bien que
  • © FUOC • P08/M2104/00604 141 Implantación, proyectos y empresas de software libre alguien con autoridad dentro del proyecto lo asigne al desarrollador más adecuado. • Asignación￿del￿error: durant les fases anteriors pot passar que un desen- volupador es faci responsable de la resolució de l'error, o bé que algú amb autoritat dins del projecte l'assigni al desenvolupador més adequat. Es esencial notificar esto en la base de datos, a fin de evitar que dos desa- rrolladores estén trabajando en la resolución del mismo error sin saberlo. Es posible notificar igualmente la fecha esperada de resolución, o la release en la que el error se habrá solucionado. • Resolución￿del￿error: Una vez el desarrollador resuelve el error, lo marca como cerrado o resuelto. A veces los errores se resuelven rápidamente, por lo que algunas de estas fases se pueden obviar. O incluso puede darse que el error no sea tal y que se deba a un mal uso por parte del usuario. En cualquier caso, por sencilla que sea la solución, siempre es conveniente registrar el error y comunicárselo adecuada- mente al usuario. Otra situación frecuente se da cuando varios usuarios notifican el mismo error, lo que se conoce como errores duplicados. En este caso es conveniente agrupar todas las notificaciones bajo una única notificación, lo que permiten concen- trar esfuerzos y disponer de toda la información en el mismo lugar. Finalmente, puede ocurrir que un error considerado como resuelto no lo esté en realidad, generalmente porque el patrón de reproducción seguido no coin- cide con el proporcionado por el usuario que ha notificado el error. En este caso, el usuario puede reabrir el error, aportando siempre toda la información necesaria. Existen numerosas forjas públicas que ofrecen estas y otras herra- mientas, listas para ser utilizadas en los proyectos de software libre. Estas pla- taformas ofrecen una serie de ventajas y desventajas. Recursos web Entre las forjas públicas más populares están SourceForge (http://www.sourceforge.net), Savannah (http://savannag.gnu.org o BerliOS.de (http://www.berlios.de). Además, algu- nas organizaciones ofrecen alojamiento a proyectos dentro de su área de interés, como Apache (http://www.apache.org) o Tigris (http://www.tigris.org). Entre sus ventajas cabe destacar su capacidad y el ancho de banda disponible: no importa el posible éxito del proyecto, los servidores siempre van a estar en funcionamiento. Vale la pena recordar el trabajo adicional que supone man- tener un servidor de alta disponibilidad en marcha. Por otra parte, las herra- mientas proporcionadas por estas forjas están ya configuradas y normalmente son muy sencillas de utilizar. Evidentemente, la desventaja principal es que la flexibilidad y las posibilidades de configuración de las herramientas ofrecidas son limitadas.
  • © FUOC • P08/M2104/00604 142 Implantación, proyectos y empresas de software libre Así, al comenzar el proyecto puede ser recomendable albergarlo en una forja pública, pero a la vez dejar abierta la posibilidad de disponer de un alojamiento propio en el futuro, empezando por registrar el nombre del dominio asociado al proyecto. Por ejemplo, el hecho de disponer de un sitio web informativo del proyecto, que redirija a una forja pública para los aspectos ligados al desarrollo del código puede ser, aunque no una solución óptima, sí un buen compromiso. 3.3.3. Organización de la comunidad Una de las mayores diferencias entre los proyectos de software libre y los pro- yectos de software propietario es el modo de organizarse de la comunidad de desarrolladores. En un proyecto de software propietario, la organización corresponde normalmente a la organización jerárquica del equipo o el departamen- to que, dentro de una empresa, lleva a cabo a cabo el desarrollo. Aun- que en un proyecto de software libre también se aprecia a veces cierta jerarquía, parcialmente basada en los méritos de cada desarrollador, la organización de la comunidad de desarrolladores es más flexible pero también más fuerte. Paradójicamente, uno de los motivos que hacen que la comunidad de desa- rrolladores trabaje y se mantenga unida es la posibilidad de crear un nuevo proyecto independiente 67 a partir del proyecto original. La posibilidad de que un proyecto de software libre se escinda es normalmente perjudicial, tanto para los desarrolladores como para los usuarios. Es precisamente esta amenaza lo que hace que la comunidad se organice y se esfuerce para tomar decisiones conjuntamente. Dicho de otro modo, el hecho de que exista la posibilidad de escisión hace que la comunidad busque un consenso más o menos democrático en las grandes decisiones del proyecto. En general, existen dos formas de organización de las comunidades de softwa- re libre, si bien la mayoría de los proyectos acaban adoptando una posición intermedia entre ambas. Estas dos formas son las siguientes: • Organización￿basada￿en￿un￿"dictador￿benevolente". El dictador benevolente es una figura con autoridad para tomar decisiones definitivas, de importancia para la vida del proyecto. Sin embargo, a me- nudo el dictador benevolente no toma las decisiones directamente, sino que suele actuar más bien de árbitro en las discusiones, tratando de com- patibilizar los puntos de vista de los desarrolladores e identificar las apor- taciones más valiosas. Otra forma de actuación del dictador benevolente es delegar en expertos que puedan ocuparse de las decisiones o discusiones en (67) En inglés, forkability, es decir la posibilidad de realizar un fork.
  • © FUOC • P08/M2104/00604 143 Implantación, proyectos y empresas de software libre marcha. El dictador benevolente suele ser un desarrollador con suficiente experiencia en el proyecto y en las tecnologías relacionadas, pero que no es necesario que sea el más experto. Basta con que sea capaz de entender el proyecto en su totalidad y reconocer las contribuciones de mayor calidad. • Organización￿basada￿en￿el￿consenso. Por consenso se entiende los acuerdos que toda la comunidad acepta más o menos tácitamente, es decir, cuando nadie se opone a las decisiones ni a la dirección que se van tomando en el proyecto, por lo que el proceso de consenso no suele ser en absoluto formal. No obstante, esto no impide que cuando no se alcanza un consenso en un determinado tema, se pueda realizar una votación. La mayoría de discusiones en la vida de un proyecto suele ser de natura- leza técnica, por lo que el consenso se produce cuando todo el mundo esta de acuerdo en, por ejemplo, el diseño o la implementación de una funcionalidad o en la manera de resolver un error. En estos casos, además, un miembro suele hacer un resumen de la discusión al final de ésta. En general todas las comunidades, y especialmente las basadas en el consen- so, tienen un excelente apoyo en el sistema de control de versiones, el cual permite volver atrás y deshacer cualquier decisión que se revele equivocada. Los proyectos suelen comenzar con una organización basada en un dictador benevolente y, a medida que la comunidad crece, se mueven hacia una orga- nización más basada en el consenso. Esto suele ocurrir en ciertos momentos de la vida del proyecto, como por ejemplo cuando el dictador benevolente abandona su posición y su autoridad se diluye en la comunidad, especialmen- te entre los miembros más respetados de ésta. Al cabo de un tiempo, las convenciones y los acuerdos tomados por una co- munidad mediante consenso pueden ser muy grandes, por lo que es conve- niente recoger los elementos principales en un documento que sirva de guía y referencia en el futuro. Éste puede incluir tanto la forma de gobierno de la comunidad, como las convenciones y las recomendaciones para los desarro- lladores. Finalmente cabe preguntarse cuál es el papel de las empresas en las comuni- dades de software libre. Por una parte podemos considerar el caso de una empresa que desee iniciar un proyecto de software libre y crear una comunidad de usuarios y desarrollado- res. Por otra parte, puede darse el caso de una empresa que se una a un proyec- to de software libre ya en marcha. En cualquiera de los dos casos, la empresa debe definir claramente sus objetivos respecto al proyecto de software libre y cuál va a ser su participación en la comunidad. Recursos web Podéis consultar las guías del proyecto Subversion (http:/ /svn.collab.net/repos/svn/ trunk/HACKING) o de la Fundación Apache (http:// www.apache.org/foundation/ how-it-works.html y http:// www.apache.org/foundation/ voting.html).
  • © FUOC • P08/M2104/00604 144 Implantación, proyectos y empresas de software libre Las posibilidades son muy variadas. Por ejemplo, la empresa puede buscar una posición de liderazgo en la comunidad y dirigir el proyecto o, sencillamente, tener voz en las discusiones, participar activamente en la implementación de nuevas funcionalidades o dedicar solamente algunos de sus desarrolladores a resolver los problemas de sus clientes. Sin olvidar la gran dificultad que supone construir un proyecto exitoso de software libre, resulta evidente que, al menos para los proyectos iniciados por una empresa, la comunidad ya existe: es la formada por los desarrolladores de la empresa y sus clientes. En esta situación, el modelo de organización basado en el dictador benevo- lente parece el más adecuado, al menos al principio, pero es necesario definir las reglas de participación de la comunidad. El reto es, por una parte, conse- guir que estos clientes se conviertan en usuarios activos y que participen en la mejora del proyecto y, por otra parte, conseguir que otros desarrolladores se involucren. La solución, si bien difícil, pasa por ofrecer ventajas o algún tipo de valor añadido a los usuarios y a los desarrolladores que participen en la comunidad. Una buena práctica consiste en que el equipo de desarrollo de la empresa tra- baje complemente integrado en la comunidad y siguiendo la metodología de desarrollo del proyecto de software libre. Esto implica que la participación de los desarrolladores en el proyecto debe ser duradera, a fin de familiarizarse con el funcionamiento de la comunidad y ganar credibilidad dentro de ella. 3.3.4. Desarrollo En este apartado se presenta el proceso de desarrollo de un proyecto de soft- ware libre, no desde el punto de vista técnico, que dependerá de la naturaleza de cada proyecto, sino desde el punto de vista de la gestión del proyecto y la coordinación de los desarrolladores. En lo que respecta al desarrollo, hay que tener en cuenta que una de las diferencias de los proyectos de software libre respecto a los proyectos de software propietario es la ausencia de una organización centralizada. Por ejemplo, cuando se aproxima la fecha de una nueva release, una empresa puede dedicar un número arbitrario de recursos a su prepara- ción. En cambio, los desarrolladores voluntarios que forman la comuni- dad no son tan fáciles de dirigir. Las motivaciones de cada uno de ellos son diferentes y, si bien algunos pueden estar interesados en publicar una nueva release a tiempo, otros pueden estar interesados solamente en alguna funcionalidad concreta.
  • © FUOC • P08/M2104/00604 145 Implantación, proyectos y empresas de software libre De este modo, la distribución de tareas en un proyecto de software libre se basa fundamentalmente en la independencia entre éstas y la regla general es que cada desarrollador trabaja en lo que desea y cuando lo desea. No obstante, esta aproximación no deja de ser en parte ideal y, en la mayoría de proyectos de software libre, resulta necesario el trabajo de una persona o equipo que coordine a todos los desarrolladores voluntarios. Por ejemplo, este equipo puede estar formado explícitamente por los iniciadores del proyecto o el dictador benevolente o, implícitamente, por los miembros con más expe- riencia y ascendencia sobre la comunidad. Algunas de las tareas principales de coordinación, necesarias para la buena marcha del proyecto, son: • Delegar: una de las tareas principales de los coordinadores del proyecto es delegar tareas en otros desarrolladores. Cuando alguien delega una ta- rea en otra persona, y ésta acepta, el beneficio es doble: el coordinador encuentra alguien que hace el trabajo por él y la otra persona, en cambio, ve reconocido su trabajo, en tanto que éste le ha sido confiado. Por ello, la mejor manera de delegar una tarea es a través de un canal de comuni- cación visible para toda la comunidad y dando siempre la opción de de- clinar la oferta. En este caso, el coordinador debe conocer las habilidades y los intereses de los miembros de la comunidad y, en función de ello, dirigir sus demandas. Por ejemplo, no tiene sentido pedir algo a alguien que no tiene la capa- cidad necesaria para llevarlo a cabo, ni tampoco a alguien que ya realiza numerosas tareas. • Realizar￿críticas￿y￿elogios: la valoración adecuada de las contribuciones de cada uno de los desarrolladores del proyecto tiene un papel muy impor- tante en la creación de un ambiente cordial dentro de la comunidad y, por supuesto, las valoraciones emitidas por los coordinadores o los miembros con mayor ascendencia tienen una mayor repercusión en la comunidad. Por ello, tanto las críticas como los elogios deben utilizarse cuidadosamen- te. Hay que recordar que las críticas continuas o injustificadas van a cau- sar seguramente una mala reacción, al igual que los elogios. Sin embargo, en una discusión técnica, una crítica detallada puede considerarse en sí misma como algo positivo, ya que implica que la persona que la realiza se ha tomado el interés de analizar el diseño o la implementación objeto de la crítica. • Evitar￿la￿territorialidad: una situación a evitar es aquella en la que ciertos miembros de la comunidad pretenden apropiarse de una parte ("su par- te") del proyecto y no aceptan ninguna crítica o contribución de los otros miembros. Aunque al principio dicha actitud puede parecer positiva, ya que tales miembros suelen ser expertos y dedican mucho tiempo a su parte del proyecto, la consecuencia a largo plazo es que ningún otro desarrolla-
  • © FUOC • P08/M2104/00604 146 Implantación, proyectos y empresas de software libre dor revisa el código realizado, con la consiguiente pérdida de calidad y la fragmentación de la comunidad. • Automatizar￿tareas: en general, la mayoría de desarrolladores trabaja en una parte del código y desconoce qué es lo que hacen los demás. Por tanto, es responsabilidad de los coordinadores tener una visión global del pro- yecto y saber a qué se dedica cada miembro. Así resulta fácil identificar una serie de tareas inherentes al desarrollo del código que todos los desa- rrolladores llevan a cabo y que a menudo puede ser conveniente automa- tizar y centralizar. El ejemplo más evidente de esto es la automatización de tests 68 , que per- mite que los desarrolladores realicen cambios y experimenten con partes del código con las que no están familiarizados. • Tratar￿adecuadamente￿a￿los￿usuarios: la existencia de una comunidad de usuarios activa y que proporcione información valiosa a los desarrolla- dores es esencial para el éxito de todo proyecto de software libre. Sin em- bargo, a menudo los desarrolladores y los usuarios hablan, por así decir- lo, lenguajes diferentes. Muchos usuarios no están familiarizados con el desarrollo de software ni con el funcionamiento de las comunidades de software libre. Los desarrolladores deben ser capaces de ponerse en el lugar de los usuarios y tratar de explicarse lo mejor posible. Hay que pensar que todo usuario puede contribuir a la comunidad en el futuro y, dado que la inmensa mayoría de usuarios no se dirige nunca a la comunidad de desarrolladores, hay que tratar con especial atención a los que sí lo hacen. Por ejemplo, cuando un usuario indica que una parte de la documentación está incompleta se le puede proponer que la complete él mismo y, cuando notifique un error, preguntarle si podría intentar resol- verlo. Y, por supuesto, agradecer siempre su contribución, sea la que sea. • Compartir￿tareas￿de￿gestión: además del desarrollo del código, todo pro- yecto lleva aparejadas una serie de tareas de gestión que, conforme el pro- yecto crece, se vuelven más complejas. Los coordinadores o el equipo que inició el proyecto suelen encargarse de ellas, pero es una buena práctica compartirlas con otros miembros del proyecto, tal y como se ha visto en el punto dedicado a la delegación. Entre estas tareas destacan: – Gestión￿de￿parches. Controlar qué parches se han recibido y analizar- los para aceptarlos o, en la mayoría de los casos, identificar sus proble- mas y notificarlos al autor del parche. – Gestión￿de￿traducciones. Coordinar la traducción de la documenta- ción y del software. – Gestión￿de￿documentación. Mantener la documentación al día e in- tegrar las modificaciones conforme éstas van apareciendo, así como la sección de preguntas frecuentes o FAQ. (68) En particular, la creación de un paquete de pruebas, un programa que ejecuta el software del pro- yecto a fin de reproducir todos los errores conocidos y corregidos an- teriormente. Esto permite que los desarrolladores se aseguren que no provocan de nuevo errores anti- guos ya resueltos.
  • © FUOC • P08/M2104/00604 147 Implantación, proyectos y empresas de software libre – Gestión￿de￿errores. Gestionar la base de datos de errores, lo que inclu- ye, entre otras funciones, asegurar su integridad y evitar la existencia de errores duplicados. • Gestionar￿permisos. una de las tareas de gestión que merece mención aparte es la gestión de los permisos o, en otras palabras, decidir quién tiene permiso para realizar commits y por tanto puede integrar su código en la copia remota del repositorio. Igualmente, la concesión de permisos impli- ca también su posible revocación. Los desarrolladores que no tienen permiso para realizar commits pueden, por supuesto, contribuir al desarrollo del proyecto, realizando parches que resuelvan errores o añadan nuevas funcionalidades y que serán analizados por los desarrolladores del proyecto y finalmente incorporados. De hecho, el mecanismo más habitual de obtención del permiso para realizar com- mits es que un desarrollador contribuya con parches al proyecto, hasta que el equipo de desarrolladores considere que sus aportaciones y su conoci- miento del proyecto son suficientemente valiosos. Para motivar la participación de nuevos desarrolladores, es conveniente que el procedimiento de obtención del permiso para realizar commits sea público y lo más transparente posible, así como su posible revocación. 3.3.5. Releasing y packaging La preparación de las releases y el empaquetado o packaging son, junto con el desarrollo del código, unas de las tareas más importantes que deben realizarse en todo proyecto de software libre. Una nueva release implica cambios, especialmente para los usuarios. En primer lugar, todos los errores conocidos de la anterior release han si- do solucionados y muy probablemente haya otros nuevos. Además, es posible que haya funcionalidades y opciones de configuración nuevas. Incluso puede que aparezcan incompatibilidades entre la nueva versión del software y las anteriores, como por ejemplo en los formatos de los datos. Ya que el cambio de una release a otra puede tener consecuencias importantes, y no todas positivas, uno de los primeros aspectos que se debe decidir es cómo se va a identificar cada una de las releases. Para ello hay un buen número de convenciones más o menos creativas, pero lo más habitual es numerarlas con una serie de dígitos separados por puntos. Por ejemplo: • Release 3.4.1
  • © FUOC • P08/M2104/00604 148 Implantación, proyectos y empresas de software libre • Release 3.4.2 • Release 3.5 • Release 4.0 El significado de los dígitos puede variar. Los cambios en el tercer dígito suelen implicar soluciones a errores o pequeñas mejoras en algunas funcionalidades. Los cambios en el segundo dígito suelen significar la introducción de nuevas funcionalidades. Finalmente, los cambios en el primer dígito implican nuevos grupos de funcionalidades y, probablemente, cambios importantes en lo que respecta a la compatibilidad entre versiones. Es conveniente indicar el significado de la numeración de las releases en el sitio web del proyecto. Además, algunas releases se suelen identificar con la palabra alpha o beta, según su estado de desarrollo. Por ejemplo: • Release 3.4.1 (alpha 1) • Release 3.4.1 (alpha 2) • Release 3.4.1 (beta) En general, la palabra alpha se utiliza para designar la primera release, la cual permite que los usuarios accedan al software con todas las funcionalidades, pero en el que se espera aún un buen número de errores. Los usuarios que instalan y ejecutan una versión alpha suelen hacerlo para evaluar el software y notificar los errores al equipo de desarrolladores. Una versión beta, en cambio, está mucho más depurada y si casi no contiene errores se convertirá en la versión oficial: es lo que se llama una versión candidata. Para los desarrolladores, un proyecto de software libre está continuamente en proceso de release, y utilizan siempre la última versión disponible en el repositorio para su desarrollo, por lo que puede ser difícil capturar el momento exacto de la release. La mejor práctica para realizar esto es mantener una rama o branch en el re- positorio que contenga el código que se introducirá en la próxima release, in- dependientemente del tronco o trunk. De este modo, además, los desarrolla- dores que no están involucrados en la preparación de la release pueden seguir trabajando en el proyecto. En consecuencia, una de las partes más importantes del proceso de prepara- ción de una release es su estabilización, es decir, decidir qué cambios y funcio- nalidades van a integrarse en la rama de la próxima release. Aquí, el mecanis- mo de toma de decisiones de la comunidad de software libre debe ponerse de nuevo en marcha y otra vez hay dos alternativas principales: Página web Podéis consultar el esque- ma de versiones del proyecto APR (http://apr.apache.org/ versioning.html).
  • © FUOC • P08/M2104/00604 149 Implantación, proyectos y empresas de software libre • Designar un propietario de la release, o release owner, que decide qué cam- bios se van a introducir en la futura release. • Votar los cambios que se van a introducir en la futura release, para lo cual es necesario definir las reglas de la votación. Una solución intermedia es fijar un número mínimo de desarrolladores que debe votar para que un determinado cambio se incluya. Además, se puede nombrar uno o dos release managers encargados de integrar y validar los cambios en la rama de la release. El software libre suele distribuirse como código fuente, adecuadamente empa- quetado y comprimido en un formato estándar 69 . El nombre del paquete sue- le estar formado por el nombre del paquete, el número de versión y el sufijo apropiado según el formato. Por ejemplo: • miproyecto-3.4.1.tar.gz • miproyecto-3.4.2.zip Entre la información que debe acompañar a toda nueva release se incluye la licencia bajo la cual se distribuye, las instrucciones de instalación y configu- ración y los cambios y las novedades respecto a la última release 70 . Esta infor- mación se recoge en una serie de archivos de número más o menos estándar: LICENSE o COPYNG, README o INSTALL, y CHANGES. (69) En sistemas GNU/Linux, la con- vención es utilizar el formato TAR, comprimido por compress, gzip, bzip o bzip2. En sistemas Windows suele utilizarse el formato ZIP. Finalmente, el usuario debe realizar la compilación del código fuente y su ins- talación en el sistema, que debe realizarse siempre de manera estándar si se desea que el software llegue al mayor número de usuarios posible. Otra posi- bilidad, empleada sobre todo con software ya maduro, es la distribución de paquetes binarios, ya sea como ejecutables o instalables, que en cualquier caso evitan que el usuario deba realizar el proceso de compilación manualmente 70 . Desde el punto de vista de la empresa de software libre, la política de releases es una de las herramientas más importantes para atraer a los usuarios potencia- les del software. Una planificación adecuada de las releases debe dar respuesta puntualmente a las necesidades de los usuarios, ya sea en nuevas funcionali- dades como en la corrección de errores, por lo que debe encontrarse el ritmo adecuado de publicación de las nuevas releases. Por ejemplo, publicar nuevas releases con demasiada frecuencia puede saturar al usuario, que probablemente no las instalaría todas y, al contrario, dejar pa- sar demasiado tiempo entre releases podría hacer que el usuario buscara solu- ciones alternativas. Del mismo modo, es conveniente asegurar la calidad de las nuevas releases, intentando corregir la mayor cantidad de errores antes de su publicación. El efecto de una release llena de errores da una imagen muy mala (70) Por ejemplo, el sistema RPM o DEB en sistemas GNU/Linux y, en sistemas Windows, los archivos MSI o ejecutables auto-instalables.
  • © FUOC • P08/M2104/00604 150 Implantación, proyectos y empresas de software libre del proyecto y de la empresa, que luego puede resultar difícil de enmendar. Por ello, es especialmente importante apoyarse en el carácter abierto y coope- rativo del software libre para mejorar su calidad. 3.3.6. Elección de licencias Las diferencias, las ventajas y los inconvenientes de cada una de las licencias de software libre es uno de los temas de discusión más recurrentes. Sin embargo, lo cierto es que la elección de una u otra licencia tiene un papel menor en la adopción y el éxito del proyecto, siempre y cuando ésta sea de software libre. La inmensa mayoría de los usuarios elige una determinada solución según la funcionalidad y la calidad que ofrece, pero no según su licencia. Lo más importante es tener claro cuáles son los objetivos del proyecto y cuá- les son los objetivos de la empresa de software libre respecto al proyecto y, en función de ello, elegir la licencia más adecuada o bien definir una nueva basada en las ya existentes 71 . Así, numerosos proyectos de software libre proporcionan su propia licencia, adaptada a sus necesidades y objetivos 72 . (71) El anexo I proporciona una lis- ta breve de las principales licencias utilizadas en la producción de soft- ware libre. (72) Por ejemplo, la licen- cia OpenBravo (http:// www.openbravo.com/product/le- gal/license/) o la licencia dual de MySQL (http://www.mysql.com/ about/legal/licensing/). Las licencias de software libre, las relaciones y las incompatibilidades poten- ciales entre ellas pueden resultar muy complejas y, en ocasiones, puede ser necesaria la ayuda de abogados o juristas especializados. Una de las principales fuentes de incompatibilidades es la reutilización de componentes libres bajo licencias restrictivas. Un ejemplo típico es la licencia GPL, que obliga a que todo software que utilice componentes GPL sea a su vez distribuido bajo licencia GPL. Una buena práctica es la realización, desde el inicio del proyecto, de un inven- tario o mapa del software externo y las licencias utilizadas en el proyecto, que describa en qué partes del código se utilizan. Ved también La asignatura del máster oficial de Software libre, Aspectos le- gales y de explotación del soft- ware libre, profundiza en estos aspectos.
  • © FUOC • P08/M2104/00604 151 Implantación, proyectos y empresas de software libre Resumen A pesar de que la tecnología basada en software libre ha sido probada, se en- cuentra en producción y funcionamiento en multitud de escenarios, y que es fácil encontrar en los medios de comunicación generalistas noticias sobre productos, eventos o personalidades relacionados con el software libre, siguen existiendo un gran número de tópicos entorno a su implantación real y efec- tiva. Estos tópicos e ideas preconcebidas a menudo juegan en contra de la implan- tación de sistemas basados en software libre, ya sea a nivel particular u orga- nizativo. Desde el punto de vista del usuario, se suele decir que el software libre es para expertos en informática o hackers, o que las aplicaciones basadas en software libre son inestables, no están terminadas, o carecen del debido soporte. Desde el punto de vista del empresario, se considera que el software libre no protege suficientemente la propiedad intelectual, que representa una pérdida de competitividad, o que salvo excepciones, no existen modelos de negocio viables entorno al software libre. En definitiva, la mayoría de estas ideas se pueden resumir en la falta de cali- dad de los procesos y productos basados en software libre, y especialmente la calidad percibida por el usuario. En cierta manera, no deja de ser cierto que la propia historia, cultura y naturaleza del software libre y de la comunidad de usuarios y desarrolladores, ha favorecido estas ideas. El creciente compromiso de administraciones públicas y grandes organizacio- nes con el software libre debería ayudar a reconsiderar la validez de estos pre- juicios. Por otra parte, numerosos expertos y analistas destacan el potencial del software libre para impulsar el desarrollo ecónomico tanto a nivel local como europeo o mundial. Por ejemplo, según Gartner "el software libre es un catalizador que va a restructurar la industria, produciendo software de calidad superior a un coste más bajo". Los materiales de esta asignatura pretenden dar respuesta a algunos de estos tópicos, formando profesionales capaces de llevar a cabo proyectos de implan- tación de sistemas de software libre a través del estudio detallado –desde un punto de vista conceptual, metodológico y práctico– de este tipo de proyectos en una variedad de escenarios y situaciones.
  • © FUOC • P08/M2104/00604 152 Implantación, proyectos y empresas de software libre En general, cabe destacar que cualquier proyecto basado en software libre se debe tratar en primer lugar como un proyecto de software y en segundo lugar como un proyecto de ingeniería, por lo que los presentes materiales no pue- den ni deben sustituir los conocimientos necesarios que són propios a estas materias. En este sentido, la mayor parte de los materiales se ha dedicado a estudiar los conceptos, metodologías y herramientas necesarios para llevar a cabo proyec- tos de desarrollo e implantación de software libre. Esto justifica el tratamien- to generalista de algunos de los contenidos, aproximando progresivamente al lector en las particularidades metodológicas de los proyectos basados en soft- ware libre, tratando de ordenar y estructurar –de forma conceptual y funcio- nal– las principales etapas e hitos de la implantación. Además, se ha presenta- do cómo la actividad económica en torno al software libre, ya sea en forma de desarrollo de software, consultoría, integración, implantación o soporte, pue- de ser objeto de un modelo de negocio lucrativo, válido y viable. Del mismo modo, y sin ser el objetivo principal de la asignatura, se han introducido los aspectos esenciales que debe cubrir todo plan de empresa, y en concreto los basados en software libre. Sin duda, la constante evolución de las tecnologías y de los proyectos de soft- ware libre dejará obsoleta al menos una parte de estos materiales, especialmen- te aquella que hace referencia a proyectos y soluciones concretas. No obstante, tanto la metodologia presentada como las referencias bibliográficas aportadas deberían ayudar a encontrar la solución adecuada para cada proyecto o esce- nario de implantación. Por otra parte, se espera que la formalización y estructuración de las metodo- logías y procedimientos presentados, así como la colección de buenas prácti- cas en proyectos de software libre, supongan una aportación cualitativa para la comunidad y para el desarrollo y expansión del software libre en general. Finalmente, no se puede finalizar estas líneas sin agradecer a la Fundació de la Universitat Oberta de Catalunya (http://www.uoc.edu) su apoyo en la elabo- ración del presente material didáctico. Al mismo tiempo, se invita a todos los lectores interesados en hacer llegar sus comentarios o sugerencias a ponerse en contacto con los autores, a fin de mejorar tanto las futuras ediciones del presente material como la práctica diaria en la implantación de sistemas ba- sados en software libre.
  • © FUOC • P08/M2104/00604 153 Implantación, proyectos y empresas de software libre Glosario ciclo de vida de un proyecto  m  Proceso que engloba, estructura, organiza y coordina todas las etapas y las fases que guían la ejecución de un proyecto y que permite afrontar la complejidad de los objetivos reduciendo el riesgo de fracaso. comunidad de software libre  f  Grupo de usuarios y desarrolladores de software libre. DAFO  m   Acrónimo de "debilidades, amenazas, fortalezas y oportunidades" (en inglés, SWOT). El análisis DAFO es una herramienta de planificación estratégica que se utiliza para evaluar las debilidades, las amenazas, las fortalezas y las oportunidades relacionadas con un proyecto. estándar abierto  m   Formato o protocolo que está sujeto a la utilización y a la evalua- ción públicas, que no depende de otros formatos o protocolos que no sean abiertos, que no contiene cláusulas que limiten su utilización, que se gestiona independientemente de los intereses particulares y que se encuentra disponible en diversas implementaciones (o en una de acceso equitativo). estudio de mercado  m  Análisis que se lleva a cabo dentro de un proyecto de iniciativa empresarial con la finalidad de hacerse una idea de la viabilidad comercial de una actividad económica, partiendo del entorno general, la competencia y los consumidores. gestión de proyectos  f  Disciplina que estudia la manera óptima de organizar y adminis- trar los recursos disponibles de forma que se pueda culminar toda tarea requerida en el pro- yecto dentro del plazo, el tiempo y el coste definidos. implantación de sistemas   f  Proceso mediante el cual se instauran una o más novedades tecnológicas en una organización, como resultado de una actuación que deriva del plan estratégico de la misma. implantación directa  f  Proceso mediante el cual el sistema que debe instaurarse no re- quiere una gran adaptación o configuración de los componentes involucrados. infraestructura  f  Conjunto de elementos o componentes de base que, estructurados, organizados y coordinados adecuadamente, facilitan el funcionamiento operacional de un sistema. insourcing  Modelo estratégico que consiste en la delegación o la producción de operaciones o trabajos en un departamento interno de la organización, normalmente especializado, en lugar de subcontratarlos a un tercero externo a la organización. licencia  f  Modelo contractual en el cual el autor del producto (o el poseedor de los derechos de autoría) establece los derechos y los deberes de los usuarios del producto y el escenario donde los pueden utilizar. licencia libre de software  f  Licencia que garantiza los cuatro principios básicos libertad: ejecutar el software con cualquier propósito, estudiar el código fuente y adaptarlo, redistribuir copias del software, mejorar el código fuente y publicar las mejoras. metodología  f  Análisis o estudio sistemático de los métodos y los procedimientos que son, han sido o pueden ser aplicados a una determinada disciplina. migración  f  Proceso de sustitución de unas infraestructuras basadas en software propieta- rio por otras con funciones equivalentes basadas en software libre. modelo de negocio  m  Estrategia empresarial que define, planifica, produce y comercializa uno o más productos o servicios orientados al lucro de sus productores. outsourcing  Modelo estratégico que consiste en la delegación o la producción de opera- ciones o trabajos en una organización externa a la organización, normalmente especializada, en lugar de delegarlos a un departamento interno de la organización. packaging o empaquetamiento  m  Proceso para automatizar la instalación, la configu- ración y la desinstalación de los paquetes de software en un ordenador. En concreto, los sis- temas GNU/Linux emplean habitualmente miles de paquetes diferentes. plan estratégico de la organización  m  Conjunto de propuestas que definen los obje- tivos o las tendencias de la organización en el futuro. Normalmente se desarrolla con poste- rioridad en las diferentes áreas o departamentos funcionales de la organización.
  • © FUOC • P08/M2104/00604 154 Implantación, proyectos y empresas de software libre software libre  m  Conjunto de programas y aplicaciones informáticas cuyas condiciones de explotación se encuentran bajo una licencia libre. proyecto  m  Proceso de gestión de recursos organizado, estructurado y planificado para alcanzar un determinado objetivo, normalmente estratégico. releasing o distribución  m  Proceso para hacer llegar la versión inicial o la actualización de un producto de software a sus usuarios potenciales. repositorio  m  Un repositorio, depósito o archivo es un lugar centralizado donde se alma- cena y mantiene información digital, habitualmente bases de datos o archivos informáticos. En el desarrollo de software libre, los repositorios incorporan un sistema de control de versio- nes que mantiene el registro de todo el trabajo y los cambios en los archivos (principalmente código fuente) que forman un proyecto y permite que diferentes desarrolladores (potencial- mente separados por grandes distancias) colaboren. riesgo  m  Acontecimiento probable que puede afectar a la marcha del proyecto y, eventual- mente, impedir que se alcancen los objetivos a tiempo. servicios del sistema   m  Conjunto de funciones que se pueden ejecutar, con o sin inter- vención del usuario, y que se consideran esenciales para el funcionamiento de la organiza- ción. sistema  m  Conjunto de elementos o componentes independientes, físicos o lógicos, que se relacionan entre sí para actuar como un conjunto integrado y funcional. soporte al usuario  m  Conjunto de servicios que de manera integral, o a partir de diversos medios de contacto, ofrece la posibilidad de gestionar y solucionar todas las posibles inci- dencias ocasionadas durante la utilización de un programa o aplicación. versión  f  Número que indica el nivel de desarrollo de un programa o aplicación.
  • © FUOC • P08/M2104/00604 155 Implantación, proyectos y empresas de software libre Bibliografía Abella, A.; Sánchez, J.; Santos, R., y otros (2003). Libro Blanco del software libre en España. [Fecha de consulta: 01 de marzo de 2008]. http://www.libroblanco.com/document/ 1000-2003.pdf Abella, A.; Segovia, M. A. (2005). Libro Blanco del software libre en España (II). [Fecha de consulta: 01 de marzo de 2008]. http://www.libroblanco.com/document/ II_libroblanco_del_software_libre.pdf Abella, A.; Segovia, M. A. (2007). Libro Blanco del software libre en España (III). [Fecha de consulta: 01 de marzo de 2008]. http://libroblanco.com/document/ III_libro_blanco_del_software_libre.pdf Clearly, D. W.; Fenn, J.; Plumer, D. C. (2005). "Gartner's Positions on the Five Hot- test IT Topics and Trends in 2005". [Fecha de consulta: 20 de mayo de 2008]. http:// www.gartner.com/DisplayDocument?doc_cd=125868 Díaz, R. M. (2007). El arte de dirigir proyectos (2a. ed.). Madrid: Ra-ma, 1995. Guitérrez, J. D. (2007). Metodología para el análisis decisorio de la implantación de soft- ware libre. [Fecha de consulta: 01 de marzo de 2008]. http://www.informaticahabana.com/ evento_virtual/files/SWL14.pdf Hecker, F. (1998). "Setting Up Shop: The Business of Open-Source Software". [Fecha de con- sulta: 01 de marzo de 2008]. http://www.hecker.org/writings/setting-up-shop.html Kerchmer, K. (2005). "The Meaning of Open Standards". Proceedings of 38 th Annual Hawaii International Conference on System Sciences 2005. [Fecha de consulta: 01 de marzo de 2008]. http://www.csrstds.com/openstds.pdf Open Formats. [Fecha de consulta: 01 de marzo de 2008]. http://www.openformats.org/ Open Source Initiative. [Fecha de consulta: 01 de marzo de 2008]. http:// www.opensource.org/ Open Standards. URL: http://www.openstandards.net/ [Fecha de consulta: 01 de marzo de 2008]. Perens, B. "Open Standards: Principles and Practice". [Fecha de consulta: 01 de marzo de 2008]. http://perens.com/OpenStandards/Definition.html Qualipso Project. URL: http://www.qualipso.org [Fecha de consulta: 20 de mayo de 2008] Sáez, D.; Peris, M.; Roca, R.; Anes, D. (2007). Migración al software libre. Guía de buenas prácticas. Instituto Tecnológico de Informática. SELF Project. URL: http://selfproject.eu [Fecha de consulta: 01 de marzo de 2008] Free Software Foundation. URL: http://www.fsf.org/ [Fecha de consulta: 01 de marzo de 2008] Vega García Pastor, I. de la (2004). El plan de negocio: una herramienta indispensable. Ins- tituto de Empresa. VV.AA. (2005). Migration guide. A guide to migrating the basic software components on server and workstation computers (2005). Berlín: Bundesministerium des Innern. [Fecha de consulta: 20 de mayo de 2008]. http://www.kbst.bund.de/cln_012/nn_836802/SharedDocs/Anlagen- kbst/Migrationsleitfaden/migration-guide-2nd- edition__pdf,templateId=raw,property=publicationFile.pdf/migration-guide-2nd- edition_pdf.pdf
  • © FUOC • P08/M2104/00604 156 Implantación, proyectos y empresas de software libre Anexo Anexo￿I:￿Licencias￿libres￿de￿software A continuación se presenta una lista breve de las principales licencias utiliza- das para la producción de software libre. Algunas de ellas se presentan con detalle en los materiales de las asignaturas de Introducción al software libre y de Aspectos legales y de explotación del software libre (2ª parte). GNU/GPL￿v3 Las siglas GNU/GPL corresponden a la licencia General Public License del pro- yecto GNU. Mantiene una política de redistribución robusta, llamada copyleft, que esta- blece que todas las obras derivadas hereden la licencia original, incluso si se han combinado con otras. No se permite el enlace desde módulos con una licencia diferente. La política de protección de los derechos originales del au- tor y de la obra, entre otros, hace que la licencia GNU/GPL no sea compatible con cualquier otra licencia, como por ejemplo la licencia BSD original o las licencias propietarias. La versión 3 de GNU/GPL no es directamente compatible con la versión 2. Sin embargo, muchos programas licenciados bajo la segunda versión permiten la utilización, en los mismos términos, de versiones posteriores de la licencia. GNU/LGPL￿v3 Recurso web Encontraréis más informa- ción sobre la licencia GNU/ GPL en http://www.gnu.org/ licenses/gpl.html. Recurso web Encontraréis una lista com- pleta de compatibilidades en http://www.gnu.org/licenses/ license-list.html. Las siglas GNU/LGPL corresponden a la licencia Lesser General Public License del proyecto GNU, una licencia derivada de GNU/GPL. Esta licencia se creó originalmente con el objetivo de permitir el uso, el enlace y la integración de bibliotecas y librerías de software libre con otros tipos de licencia, en ocasiones propietarias, salvando las restricciones de las licencias GNU/GPL. La práctica ha permitido licenciar un buen número de programas, algunos de amplia difusión en la actualidad. Entre los programas licenciados bajo GNU/LGPL figura el paquete ofimático OpenOffice.org. La versión 3 de GNU/LGPL no es directamente compatible con la versión 2. Sin embargo, muchos programas licenciados bajo la segunda versión permiten la utilización, en los mismos términos, de versiones posteriores de la licencia. Licencia￿BSD Recurso web Encontraréis más infor- mación sobre la licen- cia GNU/LGPL en http:/ /www.gnu.org/licenses/ lgpl.html.
  • © FUOC • P08/M2104/00604 157 Implantación, proyectos y empresas de software libre Las siglas BSD corresponden a la licencia Berkeley Software Distribution de la Universidad de Berkeley. Recursos web Encontraréis más información de la licencia BSD en http://www.debian.org/misc/ bsd.license. También podéis encontrar un ejemplo de licencia derivada de la BSD origi- nal en http://www.freebsd.org/copyright/freebsd-license.html, llamada licencia BSD de dos cláusulas (2-clause BSD license) debido a la abolición de dos cláusulas de la licencia original. Forma parte de un grupo de licencias (BSD-style o BSD-like licenses, entre ellas la licencia FreeBSD) denominadas permisivas, ya que mantienen una política poco restrictiva con los derechos del usuario. Esta política, llamada copycenter en oposición al término copyleft de las licencias GNU, permite entre otras cosas la aplicación comercial del producto, su conversión a código propietario y el enlace desde módulos con licencia diferente. La licencia BSD original incorpora una cláusula de publicidad que la hace in- compatible con GNU/GPL. La cláusula fue abolida en versiones posteriores, dando lugar a la llamada BSD de tres cláusulas (en inglés, 3-clause BSD license), compatible con GNU/GPL. MPL￿1.1 Las siglas MPL corresponden a la licencia Mozilla Public License de la Fundación Mozilla (Mozilla Foundation). Surgió de la iniciativa privada y es un híbrido entre las licencias BSD y GNU/ GPL. Está considerada una licencia permisiva semi-copyleft porque mantiene alguna posibilidad de establecer licencias propietarias a partir de obras deri- vadas. Permite el enlace desde módulos con licencia diferente. El artículo 13 permite licenciar una o más partes del código con una licencia diferente, lla- mada alternativa. Sólo en caso de que la licencia alternativa sea GNU/GPL -o cualquier otra de compatible-, la parte actuará como compatible con GPL, y se podrá enlazar con otros que también lo sean. Licencia￿Apache￿2.0 Página web Encontraréis más informa- ción sobre la licencia MPL en http://www.mozilla.org/ MPL/MPL-1.1.html. La licencia Apache es una licencia de la Fundación de Software Apache (Apache Software Foundation). Es bastante similar a la licencia BSD y está considerada permisiva porque man- tiene la posibilidad de establecer licencias propietarias a partir de obras deri- vadas, así como enlazarla desde módulos con licencia diferente. El uso de pa- tentes de esta licencia y las provisiones de indemnización la hacen compatible únicamente con la versión 3 de GNU/GPL, manteniendo la incompatibilidad con las dos versiones anteriores. Página web Encontraréis más informa- ción sobre la licencia Apache en http://www.apache.org/li- censes/LICENSE-2.0.
  • © FUOC • P08/M2104/00604 158 Implantación, proyectos y empresas de software libre Licencia￿X11 La licencia X11, llamada erróneamente MIT License, es una licencia del Institu- to Tecnológico de Massachussetts (Massachussetts Institute of Technology, MIT). Es bastante similar a la licencia BSD de tres cláusulas y está considerada per- misiva porque permite licenciar obras derivadas como software propietario, así como enlazarla desde módulos con licencia diferente. Es compatible con GNU/GPL y está relacionada con el proyecto X.Org. En este sentido, algunas versiones antiguas de XFree86 la continúan utilizando, mientras que las ver- siones más modernas utilizan la licencia XFree86 1.1, que es incompatible con GNU/GPL debido a los reconocimientos que se imponen en toda la documen- tación. CDDL￿1.0 Página web Encontraréis más informa- ción sobre la licencia X11 en http://www.opensource.org/ licenses/mit-license.php. Página web Encontraréis más informa- ción sobre el proyecto X.Org en http://www.x.org/. Las siglas CDDL corresponden a la licencia Common Development and Distribu- tion License de SUN Microsystems. Está basada en la versión 1.1 de la licencia MPL. Las diferencias principales se centran en dos aspectos: • El autor (o el poseedor de los derechos de autoría) puede restringir la juris- dicción legal de los derechos y los deberes de los usuarios del software.- El autor (o el poseedor de los derechos de autoría) puede restringir la juris- dicción legal de los derechos y los deberes de los usuarios del software. • La licencia establece el requisito de identificar a todos los autores que con- tribuyen a las modificaciones introducidas en las obras derivadas. Permite el enlace desde módulos con otra licencia, así como licenciar los deri- vados con una licencia diferente, eventualmente propietaria. Las característi- cas relacionadas con la propiedad intelectual la hacen incompatible con GNU/ GPL. CPL￿1.0 Página web Encontraréis más informa- ción sobre la licencia CDDL en http://www.sun.com/ cddl. Las siglas CPL corresponden a la licencia Common Public License de IBM. Su objetivo es promocionar el desarrollo de código libre, manteniendo la posi- bilidad de combinar el código con otras licencias, incluyendo licencias propie- tarias, aunque impide licenciar los derivados con otro tipo de licencia. Tam- bién prohíbe que el código derivado infrinja las patentes del original, ya que obliga al pago de cualquier royalty. Es incompatible con GNU/GPL debido a las cláusulas relacionadas con la legalidad de las obras derivadas. Página web Encontraréis más informa- ción sobre la licencia CPL en http://www-128.ibm.com/ developerworks/library/os- cpl.html.
  • © FUOC • P08/M2104/00604 159 Implantación, proyectos y empresas de software libre És incompatible amb GNU/GPL degut a les clàusules relacionades amb la le- galitat de les obres derivades. EPL￿1.0 Las siglas EPL corresponden a la licencia Eclipse Public License de la Fundación Eclipse (Eclipse Foundation). Se basa en la licencia CPL y mantiene una política permisiva orientada al ne- gocio. La principal diferencia con respecto a CPL está en el tratamiento de las infracciones de patentes por parte de los contribuyentes al software. Todo el código licenciado bajo EPL mantiene la licencia en las obras derivadas. Sin embargo, permite licenciar las adendas separadamente bajo otros tipos de li- cencia, eventualmente propietarias. Permite el enlace desde módulos con li- cencia diferente. Las características relacionadas con la permisividad de la obra derivada y la gestión de la autoría la hacen incompatible con GNU/GPL. Anexo￿II:￿Estándares￿abiertos Definición El proyecto SELF define un estándar abierto como un formato o protocolo que: Página web Encontraréis más informa- ción sobre la licencia EPL en http://www.eclipse.org/org/ documents/epl-v10.php. • está sujeto a la utilización y la evaluación pública, sin apremios, y de forma equitativa para todo el mundo; • no tiene ningún componente o extensión que dependa de formatos o pro- tocolos que no cumplan esta definición de estándar abierto; • no tiene cláusulas técnicas o legales que limiten su utilización por cual- quiera de las partes o en cualquier modelo de negocio; • ha sido gestionado y desarrollado independientemente de los intereses co- merciales particulares y mediante un proceso abierto y equitativo entre competidores y terceras partes; y • se encuentra disponible en múltiples implementaciones de diferentes ven- dedores, o bien en una sola implementación disponible equitativamente para todas las partes. Página web Encontraréis más informa- ción sobre los estándares abiertos del proyecto SELF en http://selfproject.eu/OSD. Sin embargo, no existe una definición única de estándar abierto, ya que cada organización preconiza un conjunto de características o prácticas adecuadas a sus objetivos particulares. Estas organizaciones pueden ser organizaciones de desarrollo de estándares, consejos supranacionales o gobiernos estatales. Algunas definiciones imponen la publicación en condiciones razonables y no discriminatorias (en inglés, Reasonable And Non Discriminatory (RAND)), es de- cir, no totalmente exentas de royalties. Ejemplo Como por ejemplo la defi- nición de la Unión Europea (http://europa.eu.int/idabc/ en/document/3761) o del ITU-T (http://www.itu.int/ ITU-T/othergroups/ipr-adhoc/ openstandards.html).
  • © FUOC • P08/M2104/00604 160 Implantación, proyectos y empresas de software libre Otras definiciones inciden más en las características del proceso que debe se- guir un estándar para ser abierto, como por ejemplo las recomendaciones del World Wide Web Consortium (W3C), de Bruce Perens o de Ken Krechmer. Organismos Los principales organismos, asociaciones, institutos y consorcios relacionados con los estándares de las tecnologías de la información son los siguientes: ANSI (American National Standards Institute): el Instituto Americano de Están- dares Nacionales. ETSI (European Telecommunications Standards Institute): el Instituto Europeo de Estándares de Telecomunicación (http://www.etsi.org/). FreeStandards (The Free Standards Group): organización independiente que pro- mueve la utilización y la aceptación de las tecnologías libres a través de están- dares. (http://www.freestandards.org/.) ICANN (Internet Corporation for Assigned Names and Numbers): Corporación de Internet para la Asignación de Nombres y Números (http://www.icann.org/). IEC (International Electrotechnical Commission): Comisión Internacional de Electrotecnia (http://www.iec.ch/). IEEE (Institute of Electrical and Electronics Engineers, Inc): Instituto de Ingenieros Eléctricos y Electrónicos (http://www.ieee.org/). IETF (Internet Engineering Task Force): Grupo de Trabajo en Ingeniería de Inter- net (http://www.ietf.org/). ISO (International Organization for Standardization): Organización Internacional para la Estandarización (http://www.iso.ch/). ITU (International Telecommunications Union): la Unión Internacional de Tele- comunicaciones agrupa entidades de los sectores público y privado para coor- dinar las telecomunicaciones y los servicios globales (http://www.itu.int/). JXTA (JXTA Project): se trata de una combinación de estándares abiertos de igual a igual (en inglés, peer-to-peer o P2P) con implementaciones abiertas a Java. (http://www.jxta.org/) OASIS (Organization for the Advancement of Structured Information Standards): es un consorcio internacional sin fines de lucro que orienta el desarrollo, la convergencia y la adopción de los estándares e-business (http://www.oasis- open.org/). Recursos web Encontraréis más informa- ción sobre estos procesos en: http://www.w3.org/Con- sortium/Process. http:// perens.com/OpenStan- dards/Definition.html. http://www.csrstds.com/ openstds.pdf. Página web Encontraréis más informa- ción sobre ANSI en http:// www.ansi.org/.
  • © FUOC • P08/M2104/00604 161 Implantación, proyectos y empresas de software libre OpenGroup (The Open Group): es un consorcio internacional de vendedores para el avance neutral de la tecnología (http://www.opengroup.org/). RossettaNet (Open e-business process standards): es una asociación para favore- cer los estándares abiertos en el e-business (http://www.rosettanet.org/). VoiceXML (Voice XML Forum): es una organización de industrias para crear y promover el Voice Extensible Markup Language (VoiceXML) (http:// www.voicexml.org/). W3C (World Wide Web Consortium): es un consorcio mundial para promover los estándares en Internet (http://www.voicexml.org/). WS-I (Web Services Interoperability Organization): Organización para la Intero- perabilidad de Servicios Web (http://www.ws-i.org/). Estándares￿abiertos A continuación se enumeran los principales estándares abiertos identificados por el proyecto SELF (http://selfproject.eu/en/system/files/D1_WP2.pdf). • Texto￿no￿formateado ASCII, ISO8859 (http://www.iso.org/iso/iso_catalogue/catalogue_tc/ catalogue_detail.htm?csnumber=28245) y UNICODE (http:// www.unicode.org/). • Texto￿con￿formato ODT (Open Document Text) y DocBook (http://www.oasis-open.org/com- mittees/tc_home.php?wg_abbrev=office). • Texto￿científico ODF (Open Document Formulae), MathML (Mathematical Markup Language) (http://www.w3.org/Math/) y TeX/LaTeX (http://www.tug.org/) y (http:// www.latex-project.org/). • Imágenes￿(tramas) JPEG (Joint Photographic Expert Group) (http://www.jpeg.org/) y (http:// www.w3.org/Graphics/JPEG/), PNG (Portable Network Graphics) (http:// www.libpng.org/pub/png/) y (http://www.w3.org/Graphics/PNG/), PNM (Portable Any Map) (http://netpbm.sourceforge.net/doc/pnm.html), GIF (Graphics Interchange Format) (http://www.w3.org/Graphics/GIF/spec- gif89a.txt), BMP (Bitmap) (http://atlc.sourceforge.net/bmp.html). • Imágenes￿(vectores) SVG (Scalable Vector Graphics) (http://svg.org/) y (http://www.w3.org/ Graphics/SVG/), ODG (Open Document Graphics).
  • © FUOC • P08/M2104/00604 162 Implantación, proyectos y empresas de software libre • Video OpenEXR (http://www.openexr.com/), Theora (http://theora.org/), RIFF (Resource Interchange File Format) (http://msdn2.microsoft.com/en- us/library/ms713231.aspx), AVI (Audio Video Interleave) (http:// msdn2.microsoft.com/en-us/library/ms779636.aspx). • Impresión PDF (Portable Document Format) (http://www.adobe.com/devnet/ pdf/), PS (PostScript) (http://partners.adobe.com/public/developer/ps/ index_specs.html). • Hipertexto HTML (Hyper Text Markup Language), XHTML (Extended Hyper Text Markup Language) (http://www.w3.org/MarkUp/). • Presentación ODP (Open Document Presentation). • Audio Vorbis (OGG Vorbis) (http://www.vorbis.com/) y (http://xiph.org/ ), FLAC (Free LossLess Audio Codec) (http://flac.sourceforge.net/)) y (http://xiph.org/), RIFF, WAV (Wave) (http://www.borg.com/~jglatt/tech/ wave.htm). • Educació￿i￿aprenentatge LOM (Learning Object Metadata) (http://zope.cetis.ac.uk/profiles/ uklomcore), SCORM (Sharable Content Object Reference Model) (http://www.conform2scorm.com/), IMS (http://www.imsglobal.org/ commoncartridge.html), LD (Learning Design) (http://www.imsglobal.org/ learningdesign/index.html). • Empresa XBRL (Extensible Business Reporting Language) (http://www.xbrl.org/).