Implantación de Proyectos SL

Implantacin, proyectos y empresas de software libre
Amadeu Albs Raya scar David Snchez Jimnez

P08/M2104/00604
FUOC P08/M2104/00604
ndice
Introduccin.......................................................................................... Objetivos................................................................................................. 1. Introduccin a la implantacin de sistemas basados en software libre.................................................................................. 1.1. Conceptos bsicos ..................................................................... 1.1.1. Definicin ...................................................................... 1.1.2. El plan estratgico de la organizacin ........................... 1.1.3. Origen de la implantacin de sistemas ......................... 1.1.4. Recursos de un proyecto de implantacin de sistemas .......................................................................... 1.1.5. Las principales etapas de un proyecto de implantacin de sistemas .............................................. 1.1.6. La viabilidad y la evaluacin del proyecto .................... 1.1.7. Metodologa del proyecto .............................................. 1.2. Tipologa de proyectos .............................................................. 1.2.1. Clasificacin por mbito ............................................... 1.2.2. Clasificacin por objetivo de los requerimientos .......... 1.3. Los sistemas basados en software libre ..................................... 1.4. Gestin de proyectos en software libre .................................... 1.4.1. Gestin del alcance ....................................................... 1.4.2. Gestin del tiempo ........................................................ 1.4.3. Gestin de la integracin .............................................. 1.4.4. Gestin del coste ........................................................... 1.4.5. Gestin de la calidad ..................................................... 1.4.6. Gestin de recursos humanos ....................................... 1.4.7. Gestin de la comunicacin .......................................... 1.4.8. Gestin de riesgos .......................................................... 1.4.9. Gestin de suministros .................................................. 2. El proyecto de software libre..................................................... 2.1. Ciclo de vida ............................................................................. 2.1.1. El proyecto ..................................................................... 2.1.2. Las etapas ....................................................................... 2.1.3. La ejecucin ................................................................... 2.1.4. Los resultados ................................................................ 2.2. Estudio de la situacin actual ................................................... 2.2.1. Identificacin del sistema .............................................. 2.2.2. Desarrollo del caso de estudio ....................................... 2.2.3. Evaluacin final .............................................................
7 9
11 11 11 12 13 14 15 17 18 19 19 22 26 28 28 29 32 33 33 34 34 35 36 37 37 38 40 41 42 44 45 45 47
FUOC P08/M2104/00604
2.3. Estudio de los requisitos de la implantacin ............................ 2.3.1. Identificacin y definicin ........................................... 2.3.2. Especificacin y estructuracin ..................................... 2.3.3. Verificacin .................................................................... 2.3.4. Validacin ...................................................................... 2.3.5. Evaluacin final ............................................................. 2.4. Anlisis de las soluciones en software libre ............................. 2.4.1. Bsqueda de las soluciones .......................................... 2.4.2. Anlisis y valoracin de los candidatos ......................... 2.4.3. Evaluacin final ............................................................. 2.5. Formalizacin de la propuesta .................................................. 2.5.1. Preparacin de la propuesta .......................................... 2.5.2. Diseo de la propuesta .................................................. 2.5.3. Presentacin de la propuesta ......................................... 2.5.4. Evaluacin final ............................................................. 2.6. Desarrollo .................................................................................. 2.6.1. Dotacin de recursos ..................................................... 2.6.2. Configuracin y/o desarrollo de software ..................... 2.6.3. Evaluacin final ............................................................. 2.7. Implantacin y migracin ........................................................ 2.7.1. Tipos de migracin ........................................................ 2.7.2. Estrategias de migracin ................................................ 2.7.3. Inventario de hardware y software ................................ 2.7.4. Diagrama de red y diagrama de estructura .................... 2.7.5. Ejecucin de la migracin ............................................. 2.7.6. Evaluacin de la migracin ........................................... 2.7.7. Migracin de los servicios de un sistema ...................... 2.8. Formacin, comunicacin y soporte al usuario ....................... 2.8.1. Formacin ...................................................................... 2.8.2. Introduccin del software libre ..................................... 2.8.3. Comunicacin del proyecto .......................................... 2.8.4. Sistema de soporte al usuario ........................................ 3. La empresa del software libre.................................................... 3.1. Modelos de negocio .................................................................. 3.1.1. Desarrollo ....................................................................... 3.1.2. Consultora .................................................................... 3.1.3. Instalacin e integracin ............................................... 3.1.4. Migracin de sistemas ................................................... 3.1.5. Administracin y mantenimiento de sistemas .............. 3.1.6. Soporte y formacin ...................................................... 3.2. Plan de empresa ........................................................................ 3.2.1. Resumen ejecutivo ......................................................... 3.2.2. Introduccin .................................................................. 3.2.3. Descripcin del negocio ................................................ 3.2.4. Organizacin de la produccin ..................................... 3.2.5. Organizacin interna y recursos humanos ....................
48 50 51 52 53 54 56 57 59 61 63 65 66 68 69 70 72 73 75 77 78 79 81 83 85 87 88 98 99 100 101 102 104 105 107 109 111 113 114 115 117 119 120 122 122 124
FUOC P08/M2104/00604
3.2.6. Estudio de mercado ....................................................... 3.2.7. Plan de marketing ......................................................... 3.2.8. Anlisis econmico-finaciero ......................................... 3.2.9. Forma legal .................................................................... 3.2.10. Gestin de riesgos .......................................................... 3.2.11. Resumen y evaluacin ................................................... 3.2.12. Plan de empresa y software libre ................................... 3.3. Produccin de software libre .................................................... 3.3.1. Creacin y presentacin del proyecto ........................... 3.3.2. Infraestructura ................................................................ 3.3.3. Organizacin de la comunidad ..................................... 3.3.4. Desarrollo ....................................................................... 3.3.5. Releasing y packaging....................................................... 3.3.6. Eleccin de licencias ...................................................... Resumen.................................................................................................. Glosario................................................................................................... Bibliografa............................................................................................ Anexo.......................................................................................................
125 128 130 131 132 132 133 133 135 138 142 144 147 150 151 153 155 156
FUOC P08/M2104/00604
Introduccin
En este mdulo nos adentraremos en la metodologa propia de la implantacin de sistemas basados en software libre en organizaciones y escenarios genricos, estableciendo las principales particularidades que guan el proyecto y su desarrollo. En la actualidad, la tecnologa se posiciona como factor estratgico dentro de la organizacin, ya sea pblica o privada, ya sea de pequeo tamao, medio o grande. La implicacin de la tecnologa en todos los procesos funcionales y operativos de la organizacin relaciona fuertemente su estado de funcionamiento con la produccin de la organizacin, por lo que hay que monitorizar sistemticamente la eficiencia y la eficacia del sistema con el objetivo de controlar el rendimiento frente a la evolucin de las necesidades estratgicas de la organizacin. En este sentido, la implantacin de sistemas no se puede dejar al azar o a la conveniencia de factores irrelevantes para la organizacin, ya que los resultados pueden ser imprevisibles y tener consecuencias de diferente magnitud para la organizacin. Por lo tanto, se establece la necesidad de proceder a la implantacin de un sistema con el rigor y la metodologa propias de los mbitos cientficos y tecnolgicos, que establezcan un marco de apoyo que ofrezca garantas para asumir la gestin de la complejidad, el desarrollo del proyecto y la gestin de los riesgos inherentes tanto a la tecnologa como al proceso de implantacin del sistema. El objetivo central de este mdulo es ofrecer una visin amplia y detallada de los principales procesos relacionados con la implantacin de sistemas basados en software libre, tanto desde un mbito genrico o abstracto, como desde una perspectiva especializada en las caractersticas de la gestin funcional y operativa del proyecto ligado a la implantacin del sistema, o bien considerando el negocio del software libre como mtodo vlido y viable de empresa lucrativa. Todos ellos requieren ser afrontados con una gestin metdica y rigurosa que permita por una parte abordar satisfactoriamente la complejidad de solucionar la problemtica concreta del proyecto de implantacin 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 explotacin, ambas situaciones con consecuencias importantes tanto para la organizacin, como para sus usuarios. Los contenidos de este mdulo se estructuran en tres unidades, que presentan progresivamente los conceptos tericos ms importantes del proceso de implantacin de un sistema en una organizacin. En este sentido, los apartados
FUOC P08/M2104/00604
exponen la implantacin de sistemas desde la perspectiva del software libre, analizando las principales caractersticas que conducen a garantizar el xito del proyecto, tanto desde una perspectiva de gestin del proyecto como tal, como de la implantacin del software libre como negocio lucrativo. Seguidamente, se presenta un breve resumen de las principales caractersticas de cada una de las unidades de este mdulo. El primer apartado, "Introduccin a la implantacin de sistemas", se dedica a presentar de manera general la implantacin de sistemas y las particularidades del software libre. Se define la implantacin de sistemas como una actuacin consecuente a la estrategia de la organizacin, detallando los diferentes orgenes que desencadenan la implantacin, las principales etapas del proceso, as como una clasificacin de las principales tipologas en funcin del mbito del proyecto y de su objetivo. Se presentan las particularidades del software libre, su repercusin en la implantacin de sistemas, y la gestin funcional del proyecto en trminos de alcance, tiempo, integracin, coste, calidad, recursos humanos, comunicacin y riesgos. El segundo apartado, "El proyecto de software libre", se dedica a presentar de manera exhaustiva el proyecto de implantacin de software libre desde un punto de vista metodolgico. Se define el ciclo de vida del proyecto, sus principales caractersticas, repercusiones, y relacin con los objetivos. Se presentan detalladamente las etapas de un proyecto de implantacin: estudio de la situacin actual, estudio de las incidencias en la implantacin, anlisis de las soluciones en software libre, formalizacin de la propuesta, desarrollo, implantacin y migracin, y finalmente, formacin, comunicacin y apoyo al usuario. Se define y se presenta con detalle cada una de las etapas en relacin con la consecucin de sus objetivos particulares y globales. El tercer apartado, "La empresa del software libre", se dedica a presentar de manera exhaustiva la empresa basada en el software libre, como alternativa vlida y viable en venta de copias de software. Se presentan los principales modelos de negocio relacionados con el software libre, basados principalmente en la produccin y venta de servicios complementarios. Finalmente, se presentan de manera exhaustiva las caractersticas del plan de empresa del software libre, en el cual se detallan aspectos como la definicin, los objetivos, el alcance, la organizacin, los recursos humanos y materiales, la produccin, la evolucin de los productos, el seguimiento y control de calidad, las garantas y el apoyo al usuario, la economa, la financiacin y el estudio de viabilidad del proyecto. Esperamos que la formalizacin conceptual, metodolgica y prctica de los principales aspectos ligados al proyecto de implantacin 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 consecucin de los objetivos estratgicos del proyecto.
FUOC P08/M2104/00604
Objetivos
Los objetivos de este mdulo siguiente son los siguientes:
1.
Conocer los conceptos fundamentales de la implantacin de sistemas basados en software libre.
2.
Saber identificar los diferentes tipos de proyectos de implantacin de sistemas basados en software libre.
3.
Familiarizarse con las reas de gestin de proyectos y sus particularidades aplicadas al software libre.
4. 5. 6. 7.
Conocer los elementos principales de un proyecto de software libre. Conocer las fases del ciclo de vida de un proyecto de software libre. Aprender a preparar una propuesta de proyecto de software libre. Conocer en detalle las caractersticas de un proyecto de migracin a software libre.
8. 9.
Aprender a planificar y ejecutar un proyecto de migracin a software libre. Conocer los modelos de negocio utilizados por las empresas de software libre.
10. Familiarizarse con los elementos principales de un plan de empresa o negocio. 11. Aprender a crear un plan de empresa o negocio basado en software libre. 12. Conocer las caractersticas principales de la produccin de software libre y sus particularidades.
FUOC P08/M2104/00604
11
1. Introduccin a la implantacin de sistemas basados en software libre
Este primer mdulo de la asignatura de Implantacin de sistemas de software libre proporciona las bases para conocer los principales conceptos implicados en la implantacin de sistemas en general, y su aplicacin al software libre en particular. El mdulo se inicia con un repaso de los conceptos bsicos de los proyectos de implantacin de sistemas, con la caracterizacin de las diferentes fases del proceso desde un punto de vista metodolgico y funcional y el anlisis de la estrecha relacin entre los objetivos estratgicos de la organizacin y el proyecto de implantacin. Despus, se presenta una clasificacin de los tipos de proyectos de implantacin ms habituales, indicando las principales caractersticas y diferencias entre ellos y analizando detenidamente las implicaciones en los objetivos del proyecto y en su desarrollo. Una vez se han revisado los conceptos bsicos de la implantacin de sistemas y los diferentes tipos de proyectos que incluye, se presentan las particularidades de la implantacin de sistemas en software libre. Se analizarn los principales factores que influyen en el proyecto y las ventajas y los inconvenientes de la implantacin al utilizar software libre. Finalmente, se repasarn los conceptos bsicos de la gestin de proyectos y se ampliarn los modelos clsicos para adecuarlos a las particularidades de las implantaciones basadas en software libre. 1.1. Conceptos bsicos En este primer apartado repasaremos los conceptos bsicos de la implantacin de sistemas, desde su definicin conceptual hasta las principales fases que la constituyen, sin olvidar los aspectos metodolgicos, estratgicos y organizacionales. 1.1.1. Definicin
Histricamente, la implantacin de sistemas siempre ha estado estrechamente ligada a la evolucin de la tecnologa y su difusin popular. De hecho, si se caracteriza el concepto de manera global, cualquier innovacin, tecnolgica o no, que se quiera difundir fuera del mbito estricto de sus creadores requiere seguir un proceso de implantacin.
FUOC P08/M2104/00604
12
El hecho de corresponder a una implantacin tecnolgica implica la consideracin que debe prestarse a algunos aspectos esenciales, como el impacto en la organizacin y en los usuarios directos, pero tambin en los usuarios indirectos y en los clientes, por ejemplo. Adems, actualmente se considera la tecnologa (entendida desde un punto de vista global y genrico) como un factor decisivo en la evolucin competitiva de la organizacin..
En este sentido, la implantacin de sistemas es el proceso por el cual se instauran una o ms novedades tecnolgicas en una organizacin, como resultado de una actuacin que deriva de su plan estratgico.
De acuerdo con esta definicin, la implantacin de sistemas tecnolgicos deriva de una voluntad estratgica de la organizacin para alcanzar nuevos hitos, el objetivo de los cuales puede ser muy diverso en funcin del mbito de la misma organizacin. Se puede ilustrar este concepto con dos ejemplos de mbitos diferentes: Una empresa, en tanto que organizacin con nimo de lucro, puede actuar sobre la tecnologa que utiliza con el objetivo de mejorar su competitividad y as optar a obtener ms cuota de mercado, puesto que as puede ofrecer un producto ms innovador o adecuado a nuevas demandas. Una administracin pblica, en tanto que organizacin sin nimo de lucro, puede actuar sobre la tecnologa a la cual tiene acceso la regin que administra, con el objetivo de ofrecer herramientas competitivas para minimizar la fractura digital y desarrollar la economa en este sector.
1.1.2.
El plan estratgico de la organizacin
En el anterior apartado se ha hecho referencia al plan estratgico de la organizacin y a la importancia de su papel en la implantacin de sistemas.
El plan estratgico de la organizacin es un conjunto de propuestas que definen los objetivos o tendencias de la organizacin en el futuro. Acostumbra a ser quinquenal, y tiene que desarrollarse posteriormente en las diferentes reas o departamentos funcionales de la organizacin.
El objetivo principal del plan es minimizar los riesgos y maximizar los resultados de la implantacin, mediante el establecimiento de tendencias reales, asequibles y mesurables, fruto de la relacin entre la organizacin y el mbito en el cual acta.
FUOC P08/M2104/00604 1
13
Implantacin, proyectos y empresas de software libre (1)
Muchas veces, se utiliza el anlisis DAFO como herramienta de diagnstico de la situacin actual de la organizacin, que concreta en una sola tabla los principales factores que influyen en el funcionamiento estructural de la organizacin 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 organizacin, se muestra la importancia del vnculo entre el plan estratgico de la organizacin y el proyecto de implantacin. El plan estratgico de la organizacin evoluciona con el tiempo, adaptndola dinmicamente a los cambios del entorno en el cual acta. De la misma manera, el sistema de la organizacin tiene que evolucionar con los cambios estratgicos y tiene que concluir algunas de las actuaciones emprendidas con un nuevo proyecto de implantacin de sistemas. 1.1.3. Origen de la implantacin de sistemas
DAFO es la sigla de debilidades, amenazas, fortalezas y oportunidades. En ingls, SWOT (strengths, weaknesses, opportunities, threats).
En los prrafos anteriores hemos visto el vnculo existente entre el proyecto de implantacin y el plan estratgico de la organizacin. Una organizacin no pone en marcha un proyecto de implantacin sin haber determinado que es necesario llevarlo a cabo para su estrategia particular.
As pues, la implantacin de un sistema requiere haber constatado carencias en el sistema actual de la organizacin, aunque tambin puede ser el objetivo de una implantacin en organizaciones de nueva creacin o sin posicionamiento tecnolgico previo.
A grandes rasgos, se pueden considerar cuatro orgenes genricos que pueden desencadenar una nueva implantacin de sistemas: Deteccin de problemas: puede haber casos diversos de mal funcionamiento del sistema actual, lo que compromete el trabajo habitual de los usuarios y la fiabilidad del propio sistema. En estos casos, el plan estratgico se ve afectado principalmente por la prdida de rendimiento y eficiencia de la organizacin. Un ejemplo de esta situacin podran ser los errores de programacin que comporten clculos inexactos, errores de acceso o el bloqueo del sistema. Evolucindelsistema: se trata de situaciones de obsolescencia funcional del sistema actual, lo que compromete el funcionamiento de la organizacin por falta de funcionalidades adecuadas a las crecientes incidencias en la organizacin.
FUOC P08/M2104/00604
14
En estos casos, el plan estratgico se ve afectado por la prdida de eficacia de la organizacin. Un ejemplo de esta situacin podra ser la necesidad de ampliar las funcionalidades ante un cambio de legislacin. Mejoradelsistema: se trata de situaciones de obsolescencia estructural del sistema actual, lo que compromete el funcionamiento de la organizacin por falta de rendimiento de la plataforma del sistema actual. En estos casos, el plan estratgico se ve afectado por la prdida de rendimiento y eficiencia de la organizacin. Un ejemplo de esta situacin podra ser la falta de integracin a nuevos sistemas operativos o hardware diverso. Nuevaactuacinestratgica: encontramos las posibles actualizaciones, modificaciones o novedades del plan estratgico de la organizacin que no son cubiertas por el sistema actual. En estos casos, el plan estratgico se ve afectado por la prdida de eficacia de la organizacin. Un ejemplo de esta situacin podra ser la ampliacin de los servicios ofrecidos o del mercado objetivo. La lista de posibles orgenes presentada en los prrafos anteriores no es exhaustiva, pero explica las principales razones plausibles que pueden desencadenar una implantacin. Asimismo, los diferentes casos no son excluyentes los unos de los otros, sino que su coincidencia puede depender en gran medida de la evolucin de la propia organizacin y de su sistema. 1.1.4. Recursos de un proyecto de implantacin de sistemas
(2)
Habitualmente, una vez se ha detectado la necesidad de actuar sobre el sistema actual para adecuarlo al plan estratgico de la organizacin, se dota de recursos al nuevo proyecto de implantacin de sistemas. Los recursos se suelen traducir inicialmente en disponibilidad horaria de una o ms personas para dedicarse al proyecto, con la repercusin econmica que implica tal hecho en el funcionamiento habitual de la organizacin (insourcing2). Algunas organizaciones prefieren dejar esta tarea a profesionales externos (subcontratacin o outsourcing ) por cuestiones de objetividad funcional, de capacidad de produccin o de dedicacin temporal. En estas circunstancias, la dedicacin temporal de la organizacin en el proyecto no se anula completamente, slo disminuye en la medida en que aumenta la dedicacin externa, ya que tanto la organizacin como el profesional externo se necesitan mutuamente con el fin de completar el proyecto con xito.
3
El trmino insourcing hace referencia a la delegacin o produccin interna de un proceso.
(3)
El trmino subcontratacin hace referencia a la delegacin o produccin externa de un proceso.
FUOC P08/M2104/00604
15
Uno de los puntos importantes del proyecto de implantacin, independientemente del formato final de ejecucin, es la creacin del comit supervisor o de seguimiento del proyecto (comit ejecutivo en algunas organizaciones). Este comit es el encargado de velar por una ejecucin metodolgica del proyecto y por un avance del mismo adecuado, progresivo y sostenido en el tiempo. Normalmente, el comit de supervisin est formado por personas de las diferentes reas afectadas por la implantacin, principalmente directivos y jefes de departamento. Si la organizacin hace uso de profesionales externos para gestionar la implantacin, stos tambin forman parte del comit. Aunque la dedicacin de la mayora de personas involucradas en el comit es parcial, suele haber al menos un miembro con plena dedicacin al proyecto, con el objetivo de hacer el seguimiento exhaustivo. El rol de los recursos en la implantacin de un sistema es doblemente importante: Por una parte, porque de la asignacin de los recursos humanos depender la cantidad y la calidad en el anlisis y diseo de implantacin del sistema. Por otra parte, porque de la asignacin de recursos materiales depender la cantidad y la calidad del sistema a implantar. En cualquier caso, la dotacin de recursos en un proyecto de implantacin de sistemas tiene una traduccin econmica directa para la organizacin. 1.1.5. Las principales etapas de un proyecto de implantacin de sistemas Como ya se ha comentado anteriormente, el proyecto de implantacin de sistemas es un proceso metodolgico que hay que abordar para ajustar el sistema al plan estratgico. Este proceso se tiene que llevar a cabo con el suficiente cuidado y dedicacin para garantizar el xito del proyecto.
Desde una perspectiva genrica, se pueden considerar cuatro grandes fases en el proceso de implantacin de sistemas: anlisis del sistema actual, diseo del nuevo sistema, desarrollo e implantacin del sistema.
Anlisisdelsistemaactual Todo proyecto de implantacin se inicia con el estudio y anlisis del estado actual de la organizacin en los trminos que prefigura la actuacin estratgica. Se pueden identificar dos situaciones iniciales diferentes:
FUOC P08/M2104/00604
16
Si la organizacin dispone de un sistema implantado, se evalan las caractersticas recopilando la informacin y la estructura de los elementos que influyen en la actuacin estratgica. El objetivo ser crear un marco abstracto de adecuacin del sistema a la nueva estrategia.
Si la organizacin no dispone de un sistema implantado (o es de nueva creacin), hay que evaluar las caractersticas del entorno de actuacin que son objeto del mbito estratgico de funcionamiento de la organizacin. Habr que crear un marco abstracto de objetivos que se tendrn que alcanzar con el proyecto de implantacin.
En cualquier caso, esta etapa define y determina la problemtica a la cual se enfrentar el proyecto de implantacin, con la seleccin de los diferentes objetivos de la actuacin estratgica. Se evalan aspectos como el historial del sistema, la estructura y funcionamiento o la evolucin de las incidencias y el volumen de trabajo a lo largo del tiempo. Muchos de estos resultados se presentan en forma de grficos o diagramas. Esta etapa finaliza con la presentacin de las conclusiones del estudio y anlisis del estado actual, en las que se valora la idoneidad del sistema para afrontar los nuevos retos estratgicos. Diseodelnuevosistema Una vez se ha evaluado la situacin inicial de la organizacin y se han definido los principales puntos de actuacin estratgicos, y despus de recibir la confirmacin del seguimiento por parte del comit ejecutivo del proyecto, se inicia el diseo del nuevo sistema. Esta etapa empieza con el anlisis exhaustivo de las incidencias que tiene que resolver la nueva implantacin de acuerdo con las actuaciones estratgicas definidas. A partir de estas incidencias surgirn diferentes soluciones o alternativas a implantar que habr que analizar individualmente para determinar la idoneidad, los costes, las ventajas y los inconvenientes, tanto tangibles como intangibles. En funcin del tipo de proyecto y de actuacin estratgica, esta valoracin se extiende a un periodo quinquenal. La eleccin de la solucin tiene que ser metodolgica y objetiva, buscando maximizar las ventajas y minimizar los inconvenientes, tanto de la implantacin de la solucin como de su funcionamiento habitual. Algunos criterios decisorios pueden relacionarse con la extensin de la actuacin, el rendimiento, el equipo requerido, los requisitos que cubre, el soporte del proveedor, la disponibilidad tanto del equipo como del soporte o el mantenimiento necesario a lo largo del tiempo. Desarrollodelnuevosistema
FUOC P08/M2104/00604
17
Despus de recibir la confirmacin del seguimiento del proyecto por parte del comit de supervisin, se inicia el desarrollo del nuevo sistema. El desarrollo del sistema o la adaptacin de las soluciones propuestas sigue el ciclo de vida ms 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 organizacin que da solucin a las incidencias estratgicas observadas en la etapa anterior. Implantacindelsistema Cuando se dispone del nuevo sistema, se inicia la fase de implantacin, que consiste en la puesta en marcha del sistema dentro de la organizacin. En esta fase se finaliza la adecuacin y la integracin del nuevo sistema en el entorno real. Forma parte de esta fase la formacin de los usuarios, las pruebas piloto y de integracin del sistema con los usuarios finales y la conversin y liberacin final del nuevo sistema. En caso de que la organizacin disponga de un sistema implantado, se tiene que considerar adems la migracin entre el antiguo sistema y el nuevo. La migracin consiste en la transferencia del estado actual del sistema en funcionamiento al nuevo sistema. Normalmente, el traspaso de datos es la tarea ms importante de la migracin, ya que la transferencia no tiene que impactar en el funcionamiento habitual de la organizacin. Al final de esta etapa se obtiene la implantacin definitiva del nuevo sistema, la migracin de los datos y la formacin de los usuarios. Es decir, se ha completado la instauracin de los elementos necesarios para hacer frente a la actuacin estratgica que se haba definido inicialmente. Aunque con la implantacin del sistema se cierra una parte importante del proyecto de implantacin, el mantenimiento y la constante evaluacin de la viabilidad del sistema continan activos como en todo proyecto, especialmente si se considera la nueva implantacin como factor estratgico para la competitividad de la organizacin. 1.1.6. La viabilidad y la evaluacin del proyecto
Ved tambin En la asignatura de Ingeniera del software en entornos de software libre podis encontrar ms informacin sobre el ciclo de vida de desarrollo de software.
En el apartado anterior se han descrito globalmente las principales fases de las que se compone un proyecto de implantacin de sistemas, pero adems hay que sealar tambin la importancia de al menos dos puntos de control del proyecto. El primero de ellos trata de la viabilidad y continuacin del proyecto, y se estructura en dos hitos:
FUOC P08/M2104/00604
18
El primer hito tiene lugar despus de la etapa de anlisis del estado actual, en la cual se analiza y se discute el estado actual del sistema con respecto a la actuacin estratgica.
El segundo hito tiene lugar despus de la etapa de diseo, 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 econmicas que supone su desarrollo. El segundo punto de control trata de la evaluacin del proyecto, y se enmarca temporalmente despus de la implantacin definitiva del sistema en la organizacin. En este hito se analizan las repercusiones reales del nuevo sistema una vez se ha finalizado la implantacin, evaluando los factores de impacto medibles descritos en la actuacin estratgica que ha emprendido el proceso de implantacin. El objetivo es evaluar el grado de cumplimiento del nuevo sistema con respecto a la estrategia de la organizacin. La observacin 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 organizacin o en la captacin de clientes nuevos. 1.1.7. Metodologa del proyecto
Corte longitudinal Un corte longitudinal hace referencia a que la observacin de los mensurables no es nica en el tiempo, sino que la observacin se repite diversas veces durante un periodo definido previamente.
Como en todo proyecto estratgico, la implantacin de sistemas se tiene que realizar de manera metodolgica, estructurada y ordenada. La importancia del resultado del proyecto para la evolucin de la organizacin promueve la precisin con la cual se tiene que desarrollar. A modo de ejemplo, este concepto se puede contrastar con la metodologa que se aplica al ciclo de vida en el desarrollo de un software y la importancia de las fases de anlisis conceptual y el diseo de la solucin. En esta rea, se reconoce la problemtica que proviene de no haber detectado una deficiencia en las etapas de anlisis y diseo. Globalmente, se considera que solucionar un problema de diseo detectado en la etapa de desarrollo puede tener una relacin de coste de uno a diez. De la misma manera, el proyecto de implantacin de sistemas requiere la mxima precisin en las fases de anlisis y diseo, vistas las implicaciones estratgicas que tendr la nueva implantacin en la evolucin de la organizacin. La ejecucin de las etapas descritas en los apartados anteriores tiene un comportamiento secuencial en el tiempo, inherente a su propio objetivo, pero aun as se puede especializar la metodologa de ejecucin de cada etapa con el fin de alcanzar los objetivos de manera ms eficiente. De esta manera, y a modo de ejemplo, se puede considerar la distribucin siguiente:
FUOC P08/M2104/00604
19
La fase de anlisis del sistema actual puede seguir un esquema iterativo, con realimentacin de los resultados que se obtienen en el estudio.
Las fases de diseo y desarrollo pueden seguir un esquema XP4 si se trata de desarrollar software, o clsico si se trata de una implantacin de infraestructura.
(4)
XP son las siglas de eXtreme Programming, una metodologa gil para el desarrollo de software.
La fase de implantacin puede seguir un esquema iterativo si la implantacin afecta a diversas unidades, considerando la posibilidad de mantener ms de una lnea de implantacin por unidad de tiempo.
En cualquier caso, hay que adaptar la metodologa de cada etapa a la conveniencia del proyecto y de la organizacin, siempre con el objetivo de maximizar la eficiencia y minimizar el impacto negativo. 1.2. Tipologa de proyectos En este apartado se presenta una clasificacin general de los diferentes tipos de proyectos de implantacin y se expondrn las diferentes particularidades y las principales implicaciones en el desarrollo del proyecto. Se detallan dos clasificaciones diferentes, primero segn el mbito de actuacin del proyecto, es decir, la repercusin y alcance de la implantacin, y despus segn el objeto del proyecto, es decir, el contenido de la implantacin. No se tiene que entender esta clasificacin como una estructura rgida, ya que la diversidad real de los proyectos permite la combinacin de diferentes tipologas. 1.2.1. Clasificacin por mbito
Se pueden definir tres grandes mbitos de actuacin en los proyectos de implantacin: 1)Interno
Los proyectos de mbito interno tienen por objetivo implantar un sistema local en la organizacin que sobre todo se utilizar internamente.
Por ejemplo, se pueden considerar de mbito interno proyectos de implantacin de servicios de red local (servicios de directorio, de autentificacin o de comparticin de datos), de implantacin de herramientas de trabajo en grupos locales (correo interno o herramientas de grupo groupware) o de implantacin de herramientas de gestin interna (sistemas ERP).
FUOC P08/M2104/00604
20
El objetivo estratgico de este tipo de proyectos es la mejora funcional interna, en trminos de eficiencia y eficacia del trabajo, mediante la renovacin tecnolgica. Su origen se relaciona normalmente con escenarios en que el sistema actual presenta deficiencias funcionales o falta de fiabilidad. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto. Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema desde un punto de vista funcional, con la localizacin y evaluacin de los aspectos del sistema que puedan presentar problemas, teniendo siempre como referencia la actuacin estratgica que ha previsto la organizacin. Diseodelnuevosistema: El anlisis de incidencias hecho en la etapa de diseo tiene que permitir contraponer dos alternativas para afrontar la implantacin: por un lado, la evolucin del sistema actual y, por otro, su renovacin en profundidad. Mientras que la evolucin busca la actualizacin parcial del sistema actual para alargar su vida til, la renovacin en profundidad implica cambios en diversos elementos del sistema (hardware y/o software). Desarrollodelnuevosistema: La etapa de desarrollo se mantiene sin cambios importantes. En cualquier caso, el alcance local del proyecto puede ayudar a su concrecin y resolucin estratgica. Implantacin: El mbito interno del proyecto puede ayudar a la implantacin progresiva (tiempo y/o servicios) que, conjuntamente con la formacin del personal, tendr que ayudar a crear un clima de aceptacin mientras se garantiza el funcionamiento diario de la organizacin. 2)Externo
Los proyectos de mbito externo tienen por objetivo implantar en la organizacin un sistema de utilizacin principalmente pblica, que relacione agentes externos con la organizacin. La ubicacin del sistema puede ser local o remota.
Por ejemplo, se pueden considerar de mbito externo proyectos de implantacin de intranets o extranets corporativas (acceso personalizado a trabajadores, clientes o proveedores) o de implantacin de administracin pblica electrnica (administracin electrnica o voto electrnico).
FUOC P08/M2104/00604
21
El objetivo estratgico de este tipo de proyectos es la mejora funcional de la organizacin con el exterior, en trminos de eficacia y eficiencia de la comunicacin, mediante la renovacin tecnolgica. Su origen se relaciona normalmente con escenarios en los cuales la gestin de la relacin digital con terceros es compleja o poco eficiente, y tambin en casos de mejora de la imagen corporativa y del mercado objetivo. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto. Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema desde un punto de vista relacional, comunicativo e interactivo. La recoleccin de datos no se puede restringir nicamente al interior de la organizacin, de manera que har falta el contacto con agentes externos. Tanto si existe un sistema implantado como si no, el objetivo de la actuacin estratgica ser evidenciar las carencias y debilidades de la actual implementacin relacional. Diseodelnuevosistema: El diseo del nuevo sistema tiene que responder principalmente a dos tipos de objetivos, por una parte la funcionalidad del usuario en trminos de eficiencia y eficacia y, por otra, las consideraciones relativas a la imagen corporativa que la organizacin quiere transmitir en el mercado objetivo. Desarrollodelnuevosistema: La etapa de desarrollo se mantiene sin cambios importantes. En cualquier caso, hay que destacar que la gestin de la seguridad es de especial importancia en este tipo de proyectos. Implantacin: La implantacin definitiva de estos sistemas se puede hacer en dos fases, en un primer momento se puede poner en marcha el sistema bsico, mientras que la actualizacin 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 organizacin que gestiona y/o desarrolla el proyecto (subcontratacin).
Por ejemplo, se pueden considerar de mbito productivo proyectos de implantacin de software de base (sistemas operativos), de implantacin de software especializado (herramientas ofimticas, contables, de facturacin, etc.) o de implantacin de servicios externalizados (subcontratacin de servicios web).
FUOC P08/M2104/00604
22
El objetivo estratgico de este tipo de proyectos es responder a demandas o necesidades de servicios tecnolgicos de otras organizaciones o colectivos externos de diversos mbitos. Su origen se relaciona normalmente con escenarios ligados a oportunidades de cambio tecnolgico y estratgico del mercado objetivo. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto. Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema bajo dos tendencias diferentes. Por una parte, los proyectos especializados, en los cuales hay una organizacin con necesidades estratgicas especficas por cubrir. Por otra parte, los proyectos de implantacin directa (sistemas operativos o herramientas ofimticas), destinados a producir soluciones genricas adecuadas a un conjunto amplio de mercado. En cualquier caso, se evidencia la importancia del estudio del estado de la situacin actual. Diseodelnuevosistema: La etapa de diseo no presenta cambios significativos. El proyecto especializado se lleva a cabo siguiendo las consideraciones de proyecto interno o externo en la organizacin cliente, mientras que el proyecto de implantacin directa tiene que satisfacer las necesidades habituales de funcionamiento y/o presentar innovaciones. Hay que destacar la importancia de la tecnologa utilizada en el proyecto como imagen corporativa de la organizacin. Desarrollodelnuevosistema: La etapa de desarrollo se mantiene sin cambios importantes. Hay que destacar la importancia de que el desarrollo responda con eficiencia y eficacia a los objetivos de la organizacin cliente, as como la necesidad de hacerlo en los plazos temporales estipulados. Implantacin: Los proyectos especializados siguen una implantacin de acuerdo con la tipologa de proyecto interno o externo, en la que se destaca la importancia de la formacin y la comunicacin de los usuarios. Los proyectos de implantacin 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 complementarios (formacin, migracin, etc.) y realizados bajo demanda por la misma organizacin o por terceros.
1.2.2.
Clasificacin por objetivo de los requerimientos
Se pueden definir tres grandes grupos de objetivos en proyectos de implantacin:
FUOC P08/M2104/00604
23
1)Software
Los proyectos de desarrollo de software tienen por objetivo implantar aplicaciones que respondan a determinadas exigencias. Tambin se pueden considerar de este tipo los proyectos de adaptacin, reingeniera o integracin de software o herramientas, como la adaptacin de sistemas operativos o la integracin de paquetes de software especializado.
El objetivo estratgico que persiguen este tipo de proyectos es dar una respuesta tecnolgica a una problemtica funcional concreta. Su origen se relaciona normalmente con escenarios de implantacin de sistemas de automatizacin de tareas, de soporte tecnolgico eficiente a los usuarios o de evolucin o renovacin de software obsoleto. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto. Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema desde un punto de vista funcional, evaluando la eficiencia y la eficacia del conjunto con respecto a la actuacin estratgica que inicia el proyecto. En los proyectos de creacin de software nuevo o genrico, la evaluacin se centra en el estudio y anlisis del estado actual del mercado objetivo y de las tendencias que lo guan. Diseodelnuevosistema: La etapa de diseo se mantiene sin cambios importantes con respecto al ciclo de vida de produccin de software que hemos estudiado en otras asignaturas. Hay que destacar la importancia metodolgica de las fases de anlisis de necesidades y diseo del sistema, con el objetivo de minimizar los errores que se detecten en etapas posteriores. Desarrollodelnuevosistema: La etapa de desarrollo tambin 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 cdigo producido, as como la evolucin del cdigo en versiones y revisiones. Implantacin: De la etapa de implantacin del sistema se pueden diferenciar dos tendencias. Por una parte, el desarrollo de software que hay que instalar en una organizacin, que seguir el proceso habitual teniendo en cuenta la eventual necesidad de emprender una migracin en caso de que haya un sistema implantado actualmente. Por otra parte, el software de uso comn o genrico normalmente se implanta empaquetado en forma de producto autoinstalable, en formato CD-ROM, DVD-ROM o descargaVed tambin Con respecto al ciclo de vida de produccin de software, consultad la asignatura Ingeniera del software en entornos de software libre.
FUOC P08/M2104/00604
24
ble desde Internet. Algunos servicios se pueden considerar complementarios (formacin, migracin, etc.) y realizados bajo demanda por la misma organizacin o por terceros. 2)Infraestructura
Equipamiento funcional de servicio bsico Es el caso, por ejemplo, de la instalacin y configuracin de servidores o clientes, como sistemas operativos, software de ofimtica, servicios de red bsicos (DNS, DHCP, etc.) o avanzados (correo, groupware, etc.).
Los proyectos de implantacin de infraestructura tienen por objetivo implantar sistemas de base estructural o arquitectural en un entorno determinado. Normalmente, estos proyectos se relacionan con la implantacin de equipamiento funcional de servicio bsico para la organizacin.
El objetivo estratgico que persiguen este tipo de proyectos es ofrecer una base tecnolgica funcional y adecuada a los requisitos de la organizacin. Su origen se relaciona normalmente con escenarios de nueva creacin o de renovacin tecnolgica por obsolescencia del sistema. Hay que tener en cuenta que la infraestructura de la organizacin es su arquitectura bsica funcional sobre la cual se dispondrn el resto de elementos tecnolgicos. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto: Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema desde un punto de vista funcional, considerando aspectos como la eficiencia y la eficacia pero tambin la fiabilidad y la adecuacin a los nuevos estndares que impone la evolucin tecnolgica. En los casos en que no haya un sistema ya implantado, se tendrn presentes principalmente las necesidades de la organizacin (en cantidad y calidad), as como las tendencias y estndares actuales. Diseodelnuevosistema: La etapa de diseo se centra principalmente en la investigacin y estudio de las diferentes soluciones que ofrece el mercado, aunque no se puede descartar la creacin o evolucin de una solucin si las necesidades de la organizacin lo requieren. De la comparativa tiene que surgir el producto ms adecuado a la actuacin estratgica, considerando criterios de evaluacin como la extensin, la eficiencia y eficacia de la solucin, las necesidades del equipamiento y el soporte, disponibilidad y mantenimiento del producto. Desarrollodelnuevosistema: La etapa de desarrollo del sistema comporta la preparacin de los procedimientos para implantar la infraestructura, considerando que algunas veces es necesaria la adecuacin del producto o el ajuste de ficheros de configuracin.
FUOC P08/M2104/00604
25
Implantacin: Si el nuevo sistema sustituye uno anterior, har falta un proceso de migracin de un sistema al otro. Sin embargo, en la implantacin se pueden diferenciar dos fases: en primer lugar, la instalacin y configuracin de las novedades en el nuevo sistema, y despus la puesta en funcionamiento y restauracin del estado. No hay que olvidar que, en este tipo de proyectos, la comunicacin y la formacin de los usuarios es fundamental para la aceptacin de las novedades, as como la evaluacin del funcionamiento una vez se ha puesto en marcha.
3)Migracindesistemas
Los proyectos de migracin de sistemas tienen por objetivo trasladar o transferir el estado de la arquitectura tecnolgica actual a otra diferente. Estos proyectos surgen de la actualizacin de un elemento principal del sistema o ms.
El objetivo estratgico que persiguen este tipo de proyectos es minimizar el impacto de los cambios tecnolgicos que puedan afectar al funcionamiento de la organizacin. Su origen se relaciona normalmente con escenarios de implantacin de nuevos sistemas de software o de infraestructura, aunque tambin pueden existir de manera independiente por sustitucin de la plataforma tecnolgica fsica por motivos de rendimiento, fiabilidad u obsolescencia. A continuacin se presentan las principales implicaciones en el desarrollo del proyecto: Evaluacindelsistemaactual: Esta etapa plantea principalmente la evaluacin del sistema desde un punto de vista de salvaguardia de la configuracin y de los datos almacenados. Ser importante proceder de manera metodolgica en la investigacin y evaluacin de los diferentes elementos que ser necesario migrar al nuevo sistema. Diseodelamigracin: La etapa de diseo normalmente se centra en estudiar y analizar los mtodos y procedimientos que habr que implementar para transferir el estado entre los sistemas. Se pueden considerar aspectos como la preparacin de las copias de seguridad o el diseo de los procedimientos para exportar o convertir los datos del sistema actual. Desarrollo de la migracin: El desarrollo de la migracin comporta la realizacin de todas aquellas tareas de salvaguardia de datos y configuracin, de exportacin y conversin sobre el sistema actual. Hay que valorar la importancia que tiene la ubicacin temporal de su realizacin, con el fin de garantizar el traspaso ntegro de datos sin impedir el funcionamien-
FUOC P08/M2104/00604
26
to de la organizacin. Tambin hay que tener en cuenta las garantas de seguridad que ofrece el soporte de la salvaguardia. Implantacin: La implantacin hace referencia a la puesta en marcha del nuevo sistema y la restauracin del estado del sistema anterior de la organizacin. Es importante que este proceso est planificado temporalmente de manera conjunta con la etapa de desarrollo de la migracin, con el fin de minimizar el impacto del cambio en el funcionamiento de la organizacin, aunque se puede prever la restauracin progresiva de algunos elementos menos prioritarios. En este tipo de proyectos, la comunicacin y la colaboracin con los usuarios es especialmente importante para cumplir los objetivos de la migracin con garantas de xito.
1.3. Los sistemas basados en software libre En este apartado se presentan las particularidades de la implantacin de sistemas 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 referencia a sus ventajas, bastante conocidas. As, el software libre es de distribucin libre, seguro, de calidad, se basa en estndares abiertos, puede utilizarse en cualquier lugar, se basa en la cultura de la colaboracin y la favorece, mejora la capacidad tecnolgica, permite reducir costes fijos y variables en los sistemas informticos, reduce la dependencia de proveedores y fomenta el desarrollo de las empresas locales.
Sin embargo, las empresas dedicadas a la implantacin de sistemas basados en software libre se encuentran con una serie de problemas que frenan el desarrollo del sector (Sez y otros). En general, a fin de que una tecnologa se desarrolle, es necesario que esta tecnologa sea viable comercialmente, es decir, que haya una oferta y una demanda, y econmicamente, de manera que las empresas del sector obtengan beneficios de la implantacin de la tecnologa. Con respecto a la demanda, es decir, las empresas que podran adoptar el software libre, los principales obstculos estn relacionados con la piratera, el miedo al cambio y la desconfianza. Las empresas confunden el software libre con el gratuito, y algunas compaas descartan su implantacin, o bien porque no hay software libre con niveles de calidad parecidos o bien porque no confan en que detrs haya empresas que garanticen el mantenimiento y soporte de este software.
FUOC P08/M2104/00604
27
Con respecto a la oferta, es decir, las empresas proveedoras de aplicaciones y servicios de software libre, los obstculos son bsicamente el miedo al cambio y la falta de espritu de cooperacin. Generalmente, las empresas de informtica estn 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 aparicin del software libre, algunas empresas estn viendo que puede ser un modelo de negocio sostenible aqul que se basa en el cobro por servicios y no por licencias, lo que los ha llevado a liberar parte del cdigo que hasta hoy da habr sido privado. De esta manera, una posibilidad que inicialmente podra ser utilizada por muchas empresas sera la de ofrecer dos soluciones a sus clientes, la de propiedad (con coste de licencia) y la libre (normalmente, sin coste de licencia). ste es slo uno de los muchos modelos de negocio asociados al software libre. Por otra parte, las empresas informticas tambin estn acostumbradas a desarrollar software de manera individual, y en este sentido una opcin mejor sera 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 ingeniera del software y de la gestin de proyectos. Sin embargo, un anlisis ms detallado revela algunas diferencias y particularidades, cuyo tratamiento se aprende muchas veces con la experiencia, y la omisin de las cuales puede afectar e incluso llevar al fracaso a algunos proyectos. En este contexto, la puesta en prctica de una metodologa completa para la implantacin de sistemas basados en software libre es esencial, sobre todo por dos motivos: Transmite ms confianzaalcliente con respecto a la calidad de los productos y los procesos, tanto si se trata del desarrollo de un nuevo programa o aplicacin, de la migracin de un sistema ya en funcionamiento o de la puesta en marcha de uno nuevo. Permite que las empresas proveedoras sistematicen el procedimiento de implantacin de sistemas basados en software libre y se familiaricen con sus particularidades, con la consiguiente mejora en la eficiencia y mitigacin del miedo al cambio.
FUOC P08/M2104/00604
28
1.4. Gestin de proyectos en software libre
La gestin de proyectos se divide en nueve reas de conocimiento clsicas: Alcance Tiempo Integracin Coste Calidad Recursos humanos Comunicacin Riesgos Suministros
En este apartado se revisar cada una de ellas y se estudiarn sus particularidades cuando se aplican a los proyectos de implantacin de sistemas de software libre. 1.4.1. Gestin del alcance
La gestin del alcance consiste en la definicin de los objetivos del proyecto, de manera que sea posible verificar el cumplimiento y, eventualmente, cambiarlos. Dicho de otra manera, la gestin del alcance se ocupa de que el proyecto lleve a cabo todo el trabajo necesario, y slo el trabajo necesario, para cumplir los objetivos marcados al inicio. Definicindelalcancedelproyecto Para definir el alcance de un proyecto, el jefe que lo gestiona tiene que establecer la estructura de desagregacin del proyecto (EDP), con la cual el proyecto queda dividido en paquetes de trabajo, representados habitualmente en forma de rbol lgico. Un paquete de trabajo es la unidad ms pequea en que se puede dividir un proyecto de manera que sea gestionable de independientemente. As, se identificar todo lo que se tiene que hacer en el proyecto a travs 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. Cambiosenelalcancedelproyecto A veces puede convenir modificar el alcance y los objetivos del proyecto mientras se est ejecutando. Eso se puede deber a los motivos siguientes:
FUOC P08/M2104/00604
29
Deficiencias en el plan de proyecto original, especialmente por una definicin 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 hiptesis consideradas cuando se realiz el plan de proyecto inicial.
Estas contingencias pueden afectar de manera importante a la ejecucin del proyecto, modificando e incluso impidiendo la consecucin de sus objetivos. Por ello, el control de los cambios es esencial, y se tiene que tener en cuenta en la gestin de riesgos. Gestindelalcanceenlosproyectosbasadosensoftwarelibre La gestin del alcance en proyectos basados en software libre presenta las mismas caractersticas que cualquier otro proyecto de software. Ser fundamental una captura y anlisis detallado de los requisitos del cliente, y tambin de la situacin actual del sistema cuando se trate de proyectos de migracin. En general, la definicin del alcance del proyecto basado en software libre depender de cul sea la motivacin del proyecto: reduccin de costes, mejora del sistema, independencia ante los distribuidores o regularizacin de la situacin de las licencias de software. Finalmente, es importante destacar que, a veces, el cliente puede no ser consciente de las consecuencias de los cambios en el proyecto, una vez ya se ha puesto en marcha. 1.4.2. Gestin del tiempo
La gestin 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 actividades que se tienen que realizar, as como su duracin y coordinacin. Una buena planificacin del tiempo es una herramienta fundamental en la direccin de un proyecto, ya que representa el modelo a partir del cual se llevar a cabo y permite asegurar que se estn alcanzando sus objetivos, facilita las bases para realizar la integracin del tiempo, los costes y los recursos y proporciona un marco comn para las diferentes personas y socios que participan. Reddelproyecto A partir del EDP que hemos visto en el apartado anterior, se identificarn las actividades necesarias para realizar el proyecto, teniendo presente que una actividad es la parte de trabajo ms pequea en que se puede dividir el proyecto con el fin de llevar a trmino la planificacin.
FUOC P08/M2104/00604
30
A continuacin, se identificar la secuencia en la cual se tienen que realizar las actividades: aqullas que son independientes y que pueden realizarse en paralelo y aqullas que son dependientes, es decir, que para su realizacin necesitan el resultado de una actividad precedente. DiagramadeGantt El diagrama de Gantt es el instrumento que permite resolver el problema de la programacin de actividades (es decir, su distribucin conforme a un calendario) y representar grficamente la duracin de cada actividad, sus fechas de inicio y de final y, en consecuencia, el tiempo total requerido para la ejecucin del proyecto. Adems, los diagramas de Gantt permiten controlar el progreso del proyecto, ya que indican el porcentaje realizado por cada actividad y detectan avances o retrasos en relacin con la planificacin inicial. Un diagrama de Gantt consiste en un sistema de coordenadas en el cual se representa: Eje horizontal: escala de tiempo, en las unidades ms adecuadas al proyecto, habitualmente das, semanas o meses. Eje vertical: paquetes de trabajo, actividades y subactividades identificadas en el EDP, cuya duracin se representa sobre el eje horizontal. La principal ventaja de los diagramas de Gantt es que no hace falta una gran cantidad de informacin 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. MtododelcaminocrticoyPERT Con el fin de superar las limitaciones de los diagramas de Gantt, se han desarrollado otros instrumentos, entre los cuales destacan los mtodos de camino crtico (CPM) y PERT. El camino crtico en un proyecto es la sucesin de actividades que dan lugar al mximo tiempo acumulado. Determina el tiempo ms corto que tarda a realizarse el proyecto si disponemos de todos los recursos necesarios. Para eso se tienen que identificar bien todas las actividades y debe conocerse su duracin.
FUOC P08/M2104/00604
31
Con el fin de representar las actividades y las dependencias temporales se utilizan grafos dirigidos, en los cuales cada flecha representa una actividad identificada por su nombre y duracin, de manera que el avance del proyecto modifica el estado. Cada estado se representa por un nodo entre dos o ms 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 estimacin del tiempo. El CPM considera que los tiempos de las actividades (m) se conocen de manera exacta y varan segn los recursos asignados. En cambio, el PERT supone que el tiempo de las actividades (Te) es determinado por una distribucin de probabilidad dada por la duracin estimada ms probable (m), la duracin estimada ms optimista (a) y la duracin estimada ms pesimista (b). De esta manera los tiempos pesimistas y optimistas dan una medida de la incertidumbre de cada actividad.
Para calcular el camino crtico se siguen los pasos siguientes: 1. Calcular Te o m para cada actividad, segn el mtodo utilizado. 2. Calcular las fechas mnimas de comienzo (early) de cada actividad (MIC) y las fechas mximas de comienzo (last) de cada actividad (MAC).
Clculo del MIC El MIC de cada acontecimiento se calcula como el mximo de la duracin de las actividades anteriores ms el MIC del acontecimiento anterior. El MAC es la fecha mxima en la cual pueden cumplirse los acontecimientos sin representar un retraso en la finalizacin del proyecto.
3. Calcular los mrgenes 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 acontecimiento. Margen de una actividad: Ht = MAC del acontecimiento posterior MIC del acontecimiento anterior duracin de la actividad.
4. Identificar el camino crtico del proyecto Una actividad es crtica cuando no se pueden cambiar sus instantes de comienzo y finalizacin sin modificar la duracin total del proyecto. Las actividades crticas no tienen margen y la concatenacin de actividades crticas es el caVed tambin Para profundizar en cada uno de estos mtodos, se recomienda consultar la bibliografa indicada al final del mdulo.
FUOC P08/M2104/00604
32
mino crtico. Dicho de otra manera, en una actividad crtica la fecha mnima de comienzo coincide con la ms tarda de comienzo, y la fecha ms temprana de finalizacin coincide con la fecha mxima de comienzo de la actividad. Gestindeltiempoenlosproyectosbasadosensoftwarelibre La gestin del tiempo en proyectos basados en software libre presenta en principio las mismas caractersticas que cualquier otro proyecto de software. En los proyectos de desarrollo de programas y aplicaciones en los cuales la participacin 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 comunidad y discutir el plan de implementacin futuro. Tambin es recomendable implicarse en la comunidad y familiarizarse con su forma de trabajar antes de iniciar el proyecto. En los proyectos de migracin es esencial dimensionar correctamente el tiempo necesario para llevar a cabo la formacin de los usuarios, e incluso prever cierta flexibilidad para realizar la migracin de los usuarios. En consecuencia, ciertos proyectos de software libre pueden tener asociada una incertidumbre bastante alta, por lo que resulta recomendable la utilizacin de la tcnica PERT con la finalidad de caracterizar adecuadamente los escenarios ms optimistas y pesimistas en el plan de proyecto. Hay numerosas aplicaciones libres que permiten la creacin y mantenimiento de diagramas de Gantt y PERT. 1.4.3. Gestin de la integracin
Aplicaciones libres Son aplicaciones libres, por ejemplo, GanttProject (http:// ganttproject.sourceforge.net/ ) o OpenWorkbench (http:// www.openworkbench.org/).
La gestin de la integracin tiene como objetivo asegurar que las diferentes partes del proyecto estn coordinadas correctamente. Esto incluye el desarrollo del plan del proyecto, el plan de ejecucin y el control de los cambios que se puedan llegar a producir. Gestindelaintegracinenlosproyectosbasadosensoftwarelibre La gestin de la integracin en proyectos basados en software libre presenta en general las mismas caractersticas que cualquier otro proyecto de software, pero conviene tener en cuenta ciertas particularidades.
FUOC P08/M2104/00604
33
En general, la integracin en proyectos basados en software libre presenta ciertas ventajas con respecto a los proyectos basados en software propietario, fundamentalmente a causa del cdigo abierto y del uso de estndares abiertos que facilitarn la interoperabilidad de aplicaciones, sobre todo con aqullas desarrolladas fuera del proyecto. En los proyectos de desarrollo realizados en colaboracin con una comunidad externa al proyecto, es importante hacer pblico y discutir el plan de implementacin tanto del proyecto como de la comunidad, con el fin de identificar posibles incompatibilidades que puedan dificultar la integracin. 1.4.4. Gestin del coste
La gestin del coste tiene como objetivo que el proyecto se complete con el presupuesto inicialmente aprobado. Ello comporta la planificacin de los recursos necesarios y la estimacin y el control de los costes. Gestindelcosteenlosproyectosbasadosensoftwarelibre La gestin del coste en proyectos basados en software libre difiere considerablemente 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 tendrn en cuenta los costes de servicios prestados por terceros, siguiendo cualquiera de los modelos de negocio basados en software libre. 1.4.5. Gestin de la calidad
La gestin de la calidad tiene como objetivo que el proyecto satisfaga las necesidades para las cuales fue diseado inicialmente. Para eso se tiene que planear, asegurar y controlar continuamente la calidad del proyecto en relacin con estas necesidades. Gestindelacalidadenlosproyectosbasadosensoftwarelibre La gestin del tiempo en proyectos basados en software libre presenta en principio las mismas caractersticas 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 adopcin de los estndares 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 cdigo producido desde el punto de vista de quien lo desarrolla.
FUOC P08/M2104/00604
34
Hay que respetar las recomendaciones de estilo de programacin, convenciones de nombres, documentacin, registros y formatos de error, idiomas, etc. En caso de que se trate de un nuevo proyecto, convendr hacer pblicas estas recomendaciones. 1.4.6. Gestin de recursos humanos
Estilos de programacin estndar Hay que tener en cuenta que existen estilos de programacin ya definidos y aceptados por la comunidad que conviene seguir, como las Java Code Conventions o Linux C kernel style.
La gestin de recursos humanos tiene como objetivo la utilizacin ms eficiente posible de las personas que participan en el proyecto, y entre sus actividades hay el plan organizacional, la contratacin de nuevos empleados y el desarrollo de los equipos. Gestin de los recursos humanos en los proyectos basados en software libre La gestin del tiempo en proyectos basados en software libre presenta en principio las mismas caractersticas que cualquier otro proyecto de software, pero conviene tener en cuenta ciertas particularidades. Principalmente, se tendr que evaluar la posible participacin en la comunidad de software libre y tambin la contribucin 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. Gestin de la comunicacin
La gestin de la comunicacin tiene como objetivo asegurar la correcta generacin, recoleccin, diseminacin, almacenamiento y eliminacin de la informacin del proyecto, en unos plazos determinados. Gestindelacomunicacinenlosproyectosbasadosensoftwarelibre La gestin de la comunicacin en proyectos basados en software libre presenta en principio las mismas caractersticas que cualquier otro proyecto de software. Es muy importante asegurar la comunicacin y diseminacin de la informacin dentro del proyecto, especialmente cuando se colabora con la comunidad de software libre. En caso de que no se trabaje con la comunidad de software libre, pero se previera la posibilidad de liberar el cdigo, o si el cliente deseara tener acceso al mismo, sera igualmente importante que el cdigo fuente se pudiera leer y estuviera bien documentado.
FUOC P08/M2104/00604
35
La configuracin y utilizacin correcta de los forjas de software o entornos de colaboracin de desarrollo (CDE) tiene, por lo tanto, un papel fundamental. La mayora de forjas incorpora herramientas para la gestin general del proyecto, seguimiento de errores, foros, listas de correo, etc. De la misma manera, las forjas pblicas disponen tambin de estas herramientas, y ofrecen la ventaja de ofrecer ms visibilidad a la comunidad de software libre. Entre las herramientas de comunicacin podemos destacar listas de correo, canales IRC, blogs, foros y wikis. Es importante que las decisiones relevantes tomadas a travs de estas herramientas se documenten adecuadamente y se pongan a disposicin de todos los que las desarrollen. Con respecto a la documentacin, es recomendable definir las reglas a seguir con el fin de elaborarla, as como las herramientas que se utilizarn para su generacin automtica. 1.4.8. Gestin de riesgos
Forjas de software Podis consultar ejemplos de forjados de software o entornos de colaboracin de desarrollo en las siguientes webs: Gforge, LibreSource o Trac.
Web complementaria Podis consultar un ejemplo de forja pblica en la siguiente web: http:// www.sourceforge.net.
La gestin 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 caractersticas de incertidumbre, ya que el acontecimiento que caracteriza al riesgo puede ocurrir o no, y de prdida, ya que si el acontecimiento finalmente ocurre se producirn consecuencias negativas o prdidas para el proyecto. Por ello, con el fin de caracterizar los riesgos es esencial evaluar correctamente su probabilidad y las prdidas asociadas. Existen mltiples clasificaciones de riesgos. Como primera aproximacin, se pueden considerar los siguientes tres tipos de riesgos: Riesgos de gestin, relacionados con problemas en la planificacin temporal, el presupuesto y la organizacin de personal y recursos. Riesgos tcnicos, que amenazan la calidad y la planificacin temporal del proyecto y dificultan el desarrollo y la implantacin del mismo. Los riesgos tcnicos ms frecuentes estn asociados a problemas potenciales de diseo, implementacin, verificacin o mantenimiento. Su origen suele hallarse en la existencia de ambigedades en requisitos y especificaciones y en el uso de tecnologas 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 lnea comercial de la empresa. Gestinderiesgosenlosproyectosbasadosensoftwarelibre
FUOC P08/M2104/00604
36
La gestin del riesgo en proyectos basados en software libre presenta en principio las mismas caractersticas que cualquier otro proyecto de software. Un ejemplo clsico de riesgo en los proyectos basados en software libre son los que se relacionan con el miedo y la incertidumbre tanto de la organizacin como de los usuarios del cambio tecnolgico en una nueva plataforma, eventualmente desconocida. Convendr asegurarse al inicio del proyecto de establecer mtodos de comunicacin y formacin para reducir los eventuales impactos negativos asociados al rechazo del cambio tecnolgico. Una buena prctica es establecer un periodo de presentacin, difusin y formacin de los usuarios, sostenido y progresivo a lo largo de la implantacin, que ofrezca tanto la visin global del software libre como la de aplicaciones y herramientas concretas. Otro ejemplo clsico de riesgo en los proyectos basados en software libre son las posibles incompatibilidades legales entre licencias libres, de cdigo desarrollado y reutilizado. Convendr asegurarse al inicio del proyecto que las licencias que se aplican a las diferentes partes del cdigo son coherentes entre ellas, y que los planes de desarrollo no producirn ninguna incompatibilidad. Esta misma comprobacin se tiene que realizar antes de cada release. Una buena prctica es disponer 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. Gestin de suministros
La gestin de suministros tiene como objetivos garantizar que los materiales y recursos necesarios para la ejecucin del proyecto estn disponibles a tiempo y en el lugar necesario. Gestindesuministrosenlosproyectosbasadosensoftwarelibre La gestin de suministros en proyectos basados en software libre presenta en principio las mismas caractersticas que cualquier otro proyecto de software. La migracin e implantacin 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 organizacin, 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
2. El proyecto de software libre
Un proyecto es un proceso de gestin de recursos organizado y estructurado para alcanzar un determinado objetivo, normalmente estratgico. Mientras que en la primera parte se han presentado los aspectos ms importantes de la gestin funcional de los recursos, este mdulo centra su atencin 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 implantacin de sistemas de software libre: Estudio de la situacin actual Estudio de los requisitos de la implantacin Anlisis de las soluciones en software libre Formalizacin de la propuesta Desarrollo Implantacin y migracin Formacin, documentacin y soporte al usuario
Como se puede observar, estas etapas son fruto del desarrollo de las fases presentadas en el primer apartado de esta unidad y de la aplicacin particular alrededor del software libre. Sin embargo, el desarrollo que se presenta es bastante genrico y permite que se pueda aplicar a otros procesos de implantacin. En este apartado se presenta el ciclo de vida del proyecto y ofrece una visin global del proceso, de las etapas y de su relacin con la gestin del proyecto y con los recursos que se dedican. Los siete apartados siguientes se dedicarn a desarrollar detalladamente las etapas del proyecto, enlazando y ampliando los conceptos ya presentados en el primera parte de este mdulo. 2.1. Ciclo de vida En este primer apartado se presentan las principales caractersticas metodolgicas y funcionales del ciclo de vida del proyecto, con el objetivo de proporcionar una visin global del proceso. El ciclo de vida del proyecto enlaza los aspectos metdicos, inherentes al desarrollo de las etapas de la implantacin, con la gestin funcional del proyecto. En este sentido, el ciclo de vida gua la ejecucin de las diferentes etapas a travs del tiempo y de los recursos disponibles.
FUOC P08/M2104/00604
38
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 divisin de su complejidad. Con el ciclo de vida del proyecto se puede controlar la evolucin de las etapas, el calendario temporal de ejecucin y el coste econmico del proyecto. Hay que destacar que la gestin del ciclo es dinmica, por lo que se pueden tomar decisiones de modificacin y adecuacin a lo largo del tiempo con el objetivo de reajustar la estimacin de los parmetros iniciales en funcin de los acontecimientos reales. A grandes rasgos, hay cuatro aspectos importantes del ciclo de vida: el proyecto, las etapas, la ejecucin y los resultados. 2.1.1. El proyecto
Ved tambin Podis conocer ms detalles de la gestin de los proyectos consultando el apartado de gestin de proyectos en software libre de la unidad anterior. Ved tambin Podis conocer ms detalles de la gestin del riesgo consultando el apartado sobre gestin de riesgos de la unidad anterior.
El proyecto de implantacin de sistemas, como cualquier otro proyecto, se propone la consecucin 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 proyecto conducir a minimizar los objetivos que se puedan alcanzar o a disminuir su calidad, y viceversa. En cambio, minimizar el tiempo del proyecto manteniendo los objetivos del mismo requiere un aumento de los recursos que se dedican. La gestin del proyecto busca el equilibrio ms factible entre estos tres elementos. En cualquier caso, los cambios que se producen en la relacin de estos tres elementos tienen repercusiones econmicas directas que habr que asumir en caso de actualizacin. En este sentido, la propia gestin del proyecto tiene asociado un coste econmico desde el primer momento que se inicia el proyecto (cuando se decide asignar tiempo de uno o ms trabajadores para iniciar la gestin). Normalmente, los principales factores que influyen en el tiempo y en los recursos necesarios para llevar a cabo el proyecto tienen relacin con el tamao y la complejidad del sistema a implantar. En este sentido, las caractersticas del software libre favorecen la reduccin de los costes temporales y econmicos asociados al proyecto:
FUOC P08/M2104/00604
39
Variedaddeaplicaciones. La madurez del mercado de software libre ofrece una amplia variedad de productos de implantacin directa fiables, consistentes y seguros.
Costedelaslicencias. Normalmente, el software libre se puede conseguir sin costes de licencia y se puede descargar directamente desde la web oficial o desde otros depsitos pblicos.
Modificacindelcdigofuente. La apertura del cdigo fuente permite la ampliacin, modificacin y ajuste de los productos all donde con modelos de licencias de propiedad hara falta un desarrollo nuevo, si se quisiera hacer evolucionar el producto.
Es importante destacar que el software libre tambin contribuye a disminuir el riesgo global del proyecto, gracias a las caractersticas de libertad de visualizacin, utilizacin y modificacin del cdigo fuente, que permiten evaluar y valorar en profundidad todos los aspectos de la aplicacin. Por otra parte, el proyecto se puede gestionar y ejecutar de manera interna o externa a la organizacin. A grandes rasgos, se pueden distinguir dos casos principales: Insourcing: corresponde a los casos en que la organizacin asume el desarrollo del proyecto emprendido a partir de una actuacin estratgica. Es decir, el departamento de informtica de la organizacin gestiona y ejecuta el proyecto. Outsourcingosubcontratacin: corresponde a los casos en que la organizacin delega la gestin y el desarrollo del proyecto a una organizacin externa dedicada a la gestin y ejecucin de proyectos5. Es decir, la organizacin reduce su exposicin directa al desarrollo del proyecto. En este sentido, el formato de desarrollo del proyecto se decidir considerando la capacidad y experiencia de la organizacin que tiene que asumir el desarrollo del proyecto, los costes asociados, el calendario temporal de puesta en marcha y la especializacin de las organizaciones externas en el proyecto. Finalmente, el proyecto se evala en trminos de beneficios tangibles e intangibles, y aqu se pueden dar casos en que sea plausible un sobrecoste temporal o econmico para alcanzar beneficios intangibles, normalmente estratgicos, que la organizacin requiere. Por ejemplo, mejorar la imagen corporativa con el uso y la difusin del software libre y la filosofa libre.
(5)
Por ejemplo, las consultoras tecnolgicas ejecutan proyectos por cuenta ajena.
FUOC P08/M2104/00604
40
2.1.2.
Las etapas
El ciclo de vida del proyecto se implementa en forma de etapas sucesivas y, eventualmente, simultneas en el tiempo. Cada etapa cumple un objetivo claro 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, requiere de un escenario previo con informacin sobre el entorno para producir unos determinados resultados.
En este sentido, se establece una relacin entre las diferentes etapas del proyecto, ya que cada etapa cumple una parte de sus objetivos globales. Normalmente, esta relacin puede tomar dos formas: Dependencia: entre dos etapas determina que una etapa requiere el resultado de la ejecucin de la otra para poder cumplir su tarea. Eso implica que las etapas se tendrn que ejecutar inevitablemente de manera secuencial 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 anlisis de los requisitos de la implantacin de sistemas para poder cumplir su tarea. Independencia: entre dos etapas determina que dos etapas no tengan una relacin directa ni ningn prerrequisito concreto. Eso implica que las etapas se podrn ejecutar de manera simultnea en el tiempo, aunque es posible que sean necesarios ms recursos. Por ejemplo, la etapa de implantacin del sistema podra ejecutarse de manera simultnea con la etapa de formacin de los usuarios. Por otra parte, las etapas tambin permiten la ejecucin del proyecto de manera distribuida, es decir, que una o ms etapas sean encargadas a diferentes equipos, ya sean internos o externos a la organizacin (insourcing y subcontratacin). Los casos extremos se pueden presentar cuando diversas etapas se adjudican a organizaciones externas diferentes. Todo depender de las caractersticas del proyecto, de la especializacin de las organizaciones externas y de los costes asociados. Como consecuencia de los anteriores prrafos, se pone de relieve la importancia de los entregables entre etapas. La importancia de documentar los resultados en forma de entregables es triple:
6 (6)
En ingls, deliverables.
FUOC P08/M2104/00604
41
Porque la documentacin de la etapa sintetiza el desarrollo y los resultados.
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 desarrollo del proyecto.
Las connotaciones de ejecucin interna o externa de cada etapa enfatizan la importancia de los entregables. Tambin hay que constatar que su importancia es proporcional a la complejidad y el tamao del proyecto. 2.1.3. La ejecucin
La ejecucin del proyecto se iniciar segn la planificacin inicial propuesta y siempre con el estricto seguimiento de la organizacin que es objeto de la implantacin del sistema. Globalmente, se puede destacar el seguimiento de tres parmetros principales: Tiempo. El control y gestin del tiempo es fundamental para el seguimiento del proyecto, ya que cualquier ajuste sobre este parmetro tiene consecuencias econmicas directas. Tambin es de especial importancia para el encadenamiento de las etapas, especialmente si stas estn asignadas a equipos diferentes. Subcontratacin. El control de la subcontratacin de las etapas, o eventualmente de todo el proyecto, es importante con el fin de garantizar la adecuacin del trabajo y sus resultados a los objetivos del proyecto y de la organizacin. 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 ejecucin del proyecto es fundamental para la calidad final de la implantacin. Tambin tiene que ser cualitativa la comunicacin y la transmisin de informacin entre el equipo que desarrolla el proyecto y la organizacin, con objetivos de eficiencia y eficacia. En la prctica, la ejecucin de las etapas se puede ver retardada por motivos diversos, ajenos o no al proyecto y su gestin. 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 haba previsto de manera inicial. Los retrasos acostumbran a tener una contrapartida econmica. Cuando se produce un retraso, se pueden generar dos tipos de decisiones:
FUOC P08/M2104/00604
42
Por una parte, se puede asumir el retraso en la ejecucin 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 ms recursos a una o ms etapas para mantener la cadencia temporal. Sin embargo, en algunas ocasiones asignar ms recursos no implica una mejora productiva proporcional a la asignacin.
En general, los retrasos no tendran que afectar directamente a las etapas que se ejecutan de manera simultnea a la etapa que ha sufrido un retraso. Sin embargo, eventualmente puede resultar adecuado valorar un reajuste temporal teniendo en cuenta el retraso experimentado en las otras etapas. Por ejemplo, si la implantacin del sistema ha sufrido un retraso a causa de un retraso excesivo en la recepcin de los materiales, se puede plantear retrasar voluntariamente la fase de formacin de los usuarios con el objetivo de ajustarla al momento de la implantacin. De esta manera, se evitara el decalaje entre la formacin de los usuarios y la aplicacin 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 relacin directa con los objetivos estratgicos del proyecto y de la organizacin. El ciclo de vida en s mismo slo representa una forma metdica y rigurosa de abordar la resolucin de una problemtica 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 ejecucin de las etapas, en forma de refinamientos sucesivos con el fin de solucionar la problemtica, contribuye a la adaptacin y solucin progresiva de problemas que pueden resultar de una complejidad elevada. Hay que valorar la importancia del equipo de gestin del proyecto, que con su tarea de planificacin y coordinacin colabora a que el proyecto se lleve a cabo con bastantes garantas de xito. La gestin es una tarea dinmica en el tiempo y tiene que ayudar a reajustar las diferencias que se producen entre la planificacin y la realidad a lo largo de la ejecucin del proyecto. En general, los resultados de un proyecto de implantacin de sistemas se pueden englobar en los siguientes aspectos:
FUOC P08/M2104/00604
43
Organizacin. Para la organizacin, el proyecto tiene que responder a las expectativas de la actuacin estratgica de la cual surge. Es de especial importancia poner de relieve el funcionamiento cualitativo del sistema, su integracin en la metodologa de la organizacin, la adaptacin de los usuarios y la mejora competitiva de la organizacin.
Sistema. El sistema tiene que cumplir con todos los objetivos y expectativas de la organizacin y tiene que responder de manera operativa a los objetivos de la actuacin estratgica de la organizacin. El cumplimiento de los objetivos tiene que ser cualitativo en trminos de eficiencia y eficacia funcional, tanto del propio sistema como de su interaccin con los usuarios directos e indirectos.
Usuarios. El sistema tiene el objetivo de dar soporte tecnolgico al funcionamiento de la organizacin a travs de sus usuarios. La importancia de la inclusin de los usuarios en el proyecto de implantacin es estratgica, ya que sin su participacin en el proceso y su aceptacin del sistema, la implantacin puede resultar problemtica o inviable, a ms de tener repercusiones econmicas.
Documentacin. Como en todo proyecto, la documentacin es un aspecto fundamental para la calidad del sistema implantado, para su integracin actual y evolucin futura. Desde los documentos entregables entre etapas hasta la documentacin final o los manuales de usuario, todos estos materiales 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, implantacin y formacin de los usuarios. El equipo debe permitir garantizar la interaccin y la comunicacin de todos los implicados en el proyecto durante y despus de la implantacin, bajo la forma de equipo de soporte para la formacin continuada o la resolucin de dudas y problemas.
En cualquier caso, un proyecto de implantacin de sistemas tiene que permitir que la organizacin y sus usuarios evolucionen hacia nuevos retos estratgicos. La creacin de un clima de confianza y aceptacin del cambio es fundamental para la consecucin de sus objetivos.
Aceptacin del cambio Normalmente, este proceso se llama gestindelcambio y engloba todos aquellos aspectos y procedimientos que tienen que permitir gestionar y solucionar las eventuales problemticas y reticencias a la implantacin de un nuevo sistema en la organizacin, especialmente si ste se implementa en software libre.
FUOC P08/M2104/00604
44
2.2. Estudio de la situacin actual En este apartado se define el anlisis de sistemas y se presentan las principales caractersticas y particularidades. Se detallan las diferentes fases que componen el estudio, los principales factores que influyen en su desarrollo y los resultados que se espera obtener del anlisis.
El anlisis de sistemas es una investigacin principalmente terica que tiene que permitir ofrecer una visin clara y precisa del estado del sistema de la organizacin, en referencia al mbito del proyecto y de cuya actuacin estratgica deriva.
Ved tambin Consultad los apartados sobre el plan estratgico de la organizacin y el origen de la implantacin de sistemas del primer mdulo para conocer ms aspectos de la relacin entre el proyecto de implantacin y la estrategia de la organizacin.
El anlisis de sistemas se concreta en dos aspectos complementarios: Parte del anlisis se asimila a una aplicacin tecnolgica del estudio de un caso, con la evaluacin cualitativa del sistema desde el punto de vista metodolgico y procedimental.
El estudio del caso El estudio del caso es un mtodo cientfico que permite la exploracin en profundidad de un objeto o circunstancia a travs de estrategias empricas, con el objetivo de comprender el hecho que se estudia. Normalmente se usa para la exploracin inicial y en combinacin con otras tcnicas, como por ejemplo las tcnicas cuantitativas (relacionadas con la estadstica).
Parte del anlisis se asimila al estudio de cumplimiento o competencia del sistema de la organizacin, con la evaluacin cuantitativa del sistema desde el punto de vista funcional y tecnolgico.
Las implicaciones tericas de la investigacin ponen de relieve la importancia de proceder de manera metdica, rigurosa y exhaustiva. Eventuales errores de apreciacin en esta etapa pueden provocar problemas en etapas posteriores, o incluso poner en duda la continuacin del proyecto a causa de sesgos entre el proyecto, el sistema actual y la estrategia de la organizacin, con las consiguientes repercusiones econmicas7. Aunque en este apartado se presentan las caractersticas del estudio inicial ligado a un sistema ya implantando, su estructura tambin puede ser aplicada a proyectos de nueva implantacin, trasladando el objeto de estudio al mbito de la organizacin, al mercado actual e histrico, a las tendencias tecnolgicas futuras y a otros proyectos similares que se hayan emprendido anteriormente. Tambin hay que indicar que esta primera etapa del proyecto puede no tener relacin 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 implantacin o tendencia, respectivamente.
(7)
No slo es necesario tener en cuenta el coste econmico directo de la dedicacin, sino tambin todos aqullos que son indirectos, 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
A grandes rasgos, se pueden considerar tres grandes fases dentro del anlisis de sistemas: la identificacin del sistema, la preparacin o desarrollo del caso de estudio y la evaluacin final. 2.2.1. Identificacin del sistema
La identificacin del sistema pretende definir el objeto, el alcance y los objetivos del estudio. La concrecin de estos parmetros tiene una relacin directa con la actuacin estratgica de la cual deriva el proyecto y tiene que permitir establecer el escenario de evaluacin. Hay que tener presente que un sistema ya implantado no es nicamente un conjunto de elementos tecnolgicos, sino tambin un conjunto de funcionalidades, mtodos y procedimientos con un impacto directo en los usuarios y en la organizacin en general. En este sentido, es importante destacar que el alcance del estudio tiene que incluir los elementos tecnolgicos de la implantacin, las funcionalidades que este sistema cubre actualmente, los procedimientos y mtodos de actuacin que se derivan de su interaccin con el funcionamiento de la organizacin y del impacto sobre el uso que hagan los usuarios directos e indirectos del sistema. De estos parmetros es importante determinar dos aspectos principales: Por una parte, determinar las diferentes fuentes de informacin que tienen que permitir obtener los datos para el posterior anlisis del sistema. Por otra parte, identificar la naturaleza cuantitativa o cualitativa de los datos que se obtendr de las fuentes de informacin, ya que las tcnicas para su obtencin difieren de manera sustancial.
Datos cuantitativos y datos cualitativos Los datos cuantitativos son variables numricas que cuantifican caractersticas o atributos. Por ejemplo, el nmero de usuarios activos en el sistema por unidad de tiempo. Los datos cualitativos son variables que diferencian caractersticas o atributos, no los cuantifican. Por ejemplo, la combinacin de colores de la interfaz de usuario de una aplicacin. Ved tambin En el apartado siguiente sobre desarrollo del caso de estudio se presentan las principales diferencias entre las tcnicas de obtencin de fuentes de informacin.
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 relacin de datos que es necesario obtener y la fuente de informacin asociada. 2.2.2. Desarrollo del caso de estudio
Esta fase centra su actividad en la recopilacin de todos los datos importantes para el estudio que se han detectado en la fase de identificacin del sistema.
FUOC P08/M2104/00604
46
La recopilacin de la informacin puede ser muy diversa en la prctica: fuentes documentales histricas, entrevistas en detalle, resultados de auditoras tecnolgicas, herramientas de conteo de rendimiento, documentacin de proyectos anteriores, especificaciones tecnolgicas, o incluso informes de incidencias. Es posible que en la recopilacin de datos se denoten otros aspectos interesantes pero no considerados en la fase de identificacin del sistema. En cualquier caso, la recogida tiene que ser rigurosa y mantener criterios de estructuracin y organizacin en su desarrollo. Sin embargo, se pueden diferenciar dos casos genricos para la recopilacin de datos: Datoscuantitativos. Normalmente, este tipo de datos se pueden recoger directamente de soportes tecnolgicos. El mismo sistema implantado puede disponer de contadores de rendimiento, transacciones, capacidad, volumen, etc., de los cuales se pueden obtener resultados estadsticos interesantes si se consideran unidades de tiempo o de coste, por ejemplo. Datoscualitativos. Normalmente, este tipo de datos se recogen de documentacin escrita, reuniones o entrevistas al personal. En este caso, es importante destacar el procedimiento de obtencin de informacin a partir de entrevistas y reuniones, donde su preparacin y ejecucin minuciosa permitir obtener informacin de calidad. Hay que denotar la importancia de seguir un proceso metdico que permita obtener datos tanto cuantitativos como cualitativos, ya que el sistema es una herramienta de apoyo a las personas y a la organizacin. Cualquier dato es importante desde el punto de vista de la evaluacin y valoracin 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. Adems de ser til para determinar el estado actual, puede resultar eficiente y al mismo tiempo planificar una eventual migracin del sistema. El formato final del caso acostumbra a ser un informe de investigacin, 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 definicin del proyecto, a la busca de posibles relaciones de dependencia o independencia. En funcin del tipo de informacin que se presente, puede ser til el uso de resultados estadsticos, tablas, grficos o diagramas y, en general, todo aquello que ayude a la presentacin, comprensin y valoracin de los datos que se incluyen en el informe.
Ved tambin Encontraris ms detalles del inventario de hardware y software, y de los diagramas de red en los apartados 2.7.3 y 2.7.4 de este mdulo.
FUOC P08/M2104/00604
47
Una de las herramientas ms utilizadas para la presentacin de resmenes ejecutivos es el anlisis DAFO , donde se incluyen las principales conclusiones del estudio del sistema actual desde el punto de vista estratgico. Eventualmente, y si las particularidades del proyecto lo requieren, se pueden presentar tablas DAFO que clasifiquen las diferentes caractersticas del sistema segn el resultado de su evaluacin; por ejemplo, si el hardware del sistema actual es una debilidad del sistema para afrontar la actuacin estratgica. 2.2.3. Evaluacin final
8
DAFO son las siglas de debilidades-amenazas-fortalezas-oportunidades. En ingls, SWOT.
La evaluacin final del anlisis 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 estratgicas de la organizacin y, por lo tanto, de valorar la necesidad de continuar con el proyecto. Globalmente, se pueden considerar cuatro grandes grupos de caractersticas que cabe valorar: Operativas. Tienen relacin con la interaccin funcional de los usuarios con el sistema implantado, la ergonoma, el rendimiento, la eficiencia, la eficacia o la utilidad. Organizacionales. Tienen relacin con los procedimientos y mtodos que ha generado el sistema implantado, y con los beneficios e inconvenientes que producen en la organizacin. Funcionales. Tienen relacin con la eficacia y eficiencia de las tareas que cumple el sistema implantado, la extensin, la fiabilidad, el rendimiento o los errores de funcionamiento. Econmicasylegales. Tienen relacin con el coste del sistema implantado y la regularizacin legal, como el mantenimiento, las licencias o la administracin del sistema. La evaluacin del sistema puede generar tres grandes grupos de conclusiones: Elsistemaesviable. El estudio y valoracin concluye que el sistema actual est preparado para asumir las actuaciones estratgicas de la organizacin. 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 difcil valorar la evolucin superficialmente. La evaluacin positiva del sistema actual implica la cancelacin del proyecto de implantacin, ya que no se denotan indicios que requieran una nueva implantacin. Elsistemaesparcialmenteviable. El estudio y valoracin concluye que el sistema actual requiere actualizaciones menores para poder asumir las
FUOC P08/M2104/00604
48
actuaciones estratgicas de la organizacin. Normalmente, los cambios se centran en la actualizacin o cambio de un conjunto reducido de elementos, como por ejemplo el reemplazo de dispositivos o la actualizacin del software. La evaluacin parcialmente positiva del sistema actual implica la necesidad de continuar con el proyecto de implantacin, aunque ser conveniente revisar los objetivos y el alcance para adecuarlo a las necesidades detectadas. Elsistemanoesviable. El estudio y valoracin concluye que el sistema actual no puede asumir las actuaciones estratgicas de la organizacin. Normalmente, este tipo de conclusiones se dan en casos de migracin de sistemas antiguos, que por falta de fiabilidad o rendimiento tienen que ser totalmente actualizados. La desfavorable evaluacin del sistema actual implica la necesidad de continuar con el proyecto de implantacin de un nuevo sistema. Puede ser conveniente revisar los objetivos y el alcance del proyecto, ya que la sustitucin del sistema actual puede requerir ms recursos de los previstos al inicio. Tanto el informe de anlisis como la evaluacin final del sistema actual son presentados a la organizacin por parte de la comisin de seguimiento del proyecto. Normalmente, la decisin final sobre la continuacin del proyecto corresponde al rgano director de la organizacin. El resultado de esta etapa es doble: Por una parte, se obtiene un informe completo del estado actual del sistema, donde se relevan las principales caractersticas del sistema desde el punto de vista de la estrategia de la organizacin. Por otra parte, la decisin de la organizacin respecto de la continuacin del proyecto, y las eventuales actuaciones que hay que emprender para adecuar el sistema a la estrategia de la organizacin.
2.3. Estudio de los requisitos de la implantacin En este apartado se define el estudio de requisitos de la implantacin de sistemas y se presentan las principales caractersticas y particularidades. Se detallan 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
El estudio de los requisitos del sistema es un proceso por el cual se analiza de forma metodolgica la problemtica que necesita ser solucionada.
Los objetivos del estudio de requisitos siguen dos tendencias principales: Definicindelaimplantacin. El estudio de requisitos permite concretar de forma exhaustiva todas las caractersticas que tiene que tener y permitir el nuevo sistema a implantar. En cierta manera, define los objetivos concretos y funcionales que tiene que alcanzar la implantacin. Reduccindelriesgo. El estudio de requisitos tambin permite reducir el riesgo del proyecto y de su gestin, concretando y refinando progresivamente las caractersticas de la solucin a implantar. El esfuerzo que normalmente se dedica al estudio de los requisitos de un proyecto de implantacin de sistemas es grande, por dos motivos principales: Por una parte, porque puede resultar difcil concretar y estructurar de forma metodolgica las ideas y esperanzas que tienen los usuarios y responsables de la organizacin 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 proyecto, ya que cualquier error de apreciacin cometido en esta fase y detectado en etapas posteriores tiene repercusiones econmicas y temporales sobre el proyecto o costes adicionales no previstos, que pueden poner en peligro la consecucin del proyecto9.
(9)
Un error cometido en las etapas de diseo del sistema, que sea detectado y solucionado en las etapas de desarrollo, puede llegar a tener una relacin de coste de uno a diez.
Un requisito o requerimiento es una caracterstica que tiene que cumplir el nuevo sistema. Es decir, un atributo que tiene que permitir al sistema alcanzar los objetivos fijados. El formato de los requerimientos es habitualmente textual, pero tambin 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: Polticaestratgica. Los requisitos ligados a la poltica estratgica de la organizacin se centran en aspectos generales del proyecto, de su gestin, de su resultado, o de la tendencia que tiene que seguir. Por ejemplo, la imagen y la tica corporativa, o las caractersticas histricas propias a la organizacin. Mtodosyprocedimientos. Normalmente, la implantacin de un nuevo sistema es un buen momento para actualizar y mejorar los mtodos y pro-
FUOC P08/M2104/00604
50
cesos de la organizacin y/o del sistema. Adems de revisar de forma exhaustiva los actuales procedimientos, tambin habr que tener en cuenta la especificacin de los futuros mtodos y procedimientos derivados de los nuevos objetivos o funcionalidades que tendr que cumplir el nuevo sistema. Funcionamientodelsistema. Los requisitos de funcionamiento del sistema son derivados de la interaccin de los usuarios con el sistema. Hay que diferenciar los requisitos funcionales de los no funcionales: los funcionales corresponden a acciones especficas 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 mtodos y procedimientos. Factoresclaveyprioridades. La mayora de sistemas tienen un determinado nmero de elementos principales, en cierta manera, forman parte del ncleo del sistema. En una nueva implantacin, se puede dar prioridad o preferencia a aquellos componentes que se consideran indispensables para el funcionamiento del sistema y de la organizacin, as como otros componentes que no la tienen pueden ser considerados con una prioridad ms baja.. Tambin hay que denotar que la etapa de recogida de requisitos no tiene una relacin directa con el software libre, ya que la implantacin de sistemas en software libre tiene que cumplir los mismos requisitos y objetivos que cualquier otro tipo de implantacin. A grandes rasgos, se pueden considerar cinco grandes fases para el estudio de los requerimientos de un sistema: la identificacin y definicin, la especificacin y estructuracin, la verificacin, la validacin, y la evaluacin final. 2.3.1. Identificacin y definicin
Ved tambin Consultad el apartado 1.2 del primer mdulo para conocer los diferentes tipos de proyectos de implantacin de sistemas.
Esta primera fase del estudio de requerimientos pretende identificar y definir la problemtica que se tiene que resolver y la tipologa del proyecto, as como determinar las principales fuentes de informacin para la recogida de datos. La etapa de estudio de requisitos parte de la informacin documental de la etapa de anlisis del estado actual, de tal forma que parte de la tarea de identificacin de la problemtica ya est concretada previamente. Hay que identificar dentro de la organizacin a los implicados directos e indirectos, y definir el alcance de la problemtica dentro de la organizacin, los implicados directos e indirectos, ya sean humanos, materiales, funcionales, organizacionales, procedimentales o tecnolgicos. Normalmente, todos estos elementos permitirn recuperar informacin fundamental para la definicin
FUOC P08/M2104/00604
51
del nuevo sistema que, conjuntamente con el informe del estado actual, permitirn establecer un corpus de conocimiento adecuado para la toma de decisiones. Tambin es importante destacar el rol que juega la tendencia del mercado actual en la definicin de requisitos. Conocer las particularidades de sistemas similares, organizaciones del mismo sector, ltimas innovaciones o tendencias futuras en la temtica del proyecto, pueden ser de gran ayuda para concretar, proponer, evaluar y comprender las peticiones de los usuarios y responsables de la organizacin. El resultado de esta primera fase suele representarse en un documento de trabajo con la definicin exhaustiva del objetivo y el alcance del proyecto, una relacin de elementos a considerar, fuentes de informacin interna a la organizacin, y una relacin de elementos o tendencias de mercado susceptibles de contener informacin relevante para el proyecto. 2.3.2. Especificacin y estructuracin
La fase de especificacin y estructuracin pretende recoger los datos relevantes de todos los elementos identificados anteriormente, y organizarlos bajo criterios metodolgicos 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 aproximacin a los elementos y fuentes de informacin susceptibles de contener informacin relevante para el proyecto. Sin embargo, el desarrollo prctico del estudio puede llevar a considerar nuevas fuentes de informacin y nuevos aspectos relevantes para el proyecto, que no se haban 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: Recoleccin y especificacin. Trata de resolver las funcionalidades del sistema. Es decir, qu hace falta que el sistema haga, no cmo lo tiene que hacer. Algunas fuentes de informacin tienen tendencia a centrarse en cmo realizar las acciones en lugar de determinar las particularidades de la tarea en s misma. Estructuracinyorganizacin. Trata de organizar los datos de forma metdica y comprensible. Es importante destacar que puede ser conveniente priorizar algunos requisitos antes que otros, en consonancia con los elementos del sistema que son indispensables para su funcionamiento.
FUOC P08/M2104/00604
52
De la misma forma que en el estudio de la situacin actual, la recoleccin de los datos puede responder a criterios cuantitativos o cualitativos: Datoscuantitativos. Provienen normalmente de soportes tecnolgicos, y permiten el tratamiento masivo para obtener resultados estadsticos 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 funcionales respecto del sistema, as como los procedimientos y los mtodos que se ven afectados por el proyecto. Los requisitos de implantacin de sistemas se relacionan con los elementos bsicos de todo sistema, como por ejemplo el hardware, el software, la infraestructura, el personal, los procedimientos, las funcionalidades, o incluso los idiomas, la documentacin, los formatos y los estndares. El formato de presentacin de los requisitos acostumbra a ser textual, organizados segn las caractersticas del proyecto, del sistema y de las particularidades de los mismos requisitos. Tambin se pueden utilizar tablas, grficos o diagramas con el objetivo de mejorar la definicin, el razonamiento y la apreciacin de los conceptos que se presentan. El resultado de esta fase suele representarse en un documento de trabajo con la presentacin de todos los requisitos organizados, estructurados y justificados de acuerdo con el ideario del proyecto. La precisin y claridad de este documento es fundamental para todo el proyecto, ya que no slo depende todo el desarrollo posterior del mismo, sino tambin la aceptacin por parte de la organizacin de los trminos de la implantacin final. 2.3.3. Verificacin
La fase de verificacin de los requisitos pretende evaluar los requisitos recogidos y especificados en las fases anteriores, y valorarlos respecto de la coherencia como sistema y con las pretensiones de la organizacin. Esta fase parte del documento de trabajo de la anterior fase, que recoge de forma organizada y metdica los requisitos obtenidos en el estudio. La verificacin formal de los requisitos se compone de dos grandes procesos: Anlisistecnolgico. El anlisis tecnolgico de los requisitos es un proceso que pretende analizar y concluir que todos los requisitos recogidos son complementarios y que forman un sistema lgico, razonable y viable de ser implantado.
FUOC P08/M2104/00604
53
En esta fase se suelen detectar requisitos antagnicos, fruto de las diversas fuentes de recogida de informacin. El conflicto se puede resolver consultando las otras caractersticas recogidas en los requisitos y/o validando las opciones con los implicados directos o con la organizacin. Anlisisfuncional. El anlisis funcional de los requisitos es un proceso que pretende analizar y concluir que el sistema que se deriva de la implementacin de los requisitos responde a los requisitos y objetivos del proyecto y de la organizacin. En esta fase se pueden detectar asunciones errneas en los requisitos, que pueden ser antagnicas respecto de los objetivos del proyecto. El conflicto se puede resolver con la revisin y consulta de los aspectos problemticos con los implicados directos y/o con la organizacin. El proceso de verificacin de los requisitos es eminentemente tecnolgico y metodolgico, cuestionando la coherencia y viabilidad de la eventual implementacin e implantacin del sistema que se define en los requisitos. Eventualmente, puede ser interesante la participacin de diversas personas en la revisin de los requisitos. Los diferentes puntos de vista pueden ayudar a identificar y solucionar los posibles errores o carencias de forma ms efectiva. De la revisin tambin pueden surgir nuevas cuestiones o situaciones que no se haban planteado hasta el momento, lo que puede inducir a un bucle entre la recogida de requisitos y su verificacin, hasta que haya convergencia y coherencia en los resultados (proceso parecido a la metodologa por refinamientos sucesivos).
Metodologa top-down La metodologa top-down, o por refinamientos sucesivos, parte de la definicin general de la problemtica 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 actualizacin del documento de trabajo con los requisitos, ya creado en la fase anterior. La actualizacin ha permitido la revisin en detalle de los conceptos de la implantacin, adems de identificar y resolver los posibles errores que podan existir en la relacin de requisitos inicial. 2.3.4. Validacin
La fase de validacin de los requisitos pretende acordar los requisitos de la implantacin del nuevo sistema fruto del estudio llevado a cabo con la organizacin. El acuerdo de los requisitos es la herramienta fundamental para la formalizacin contractual de la implantacin del sistema.
FUOC P08/M2104/00604
54
Esta fase requiere la participacin activa de la organizacin, que tiene que analizar en profundidad la propuesta de requisitos que resulta de las anteriores fases. Hay que denotar la importancia de la transmisin de informacin entre ambos colectivos, ya que las caractersticas de la implantacin del sistema dependen de la comprensin del estudio de requisitos. Eventualmente, el documento de trabajo interno que recoge los requisitos puede 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 informacin de forma ms clara, efectiva y grfica. El proceso de validacin de los requisitos por parte de la organizacin puede concluir en nuevas revisiones de los requisitos. Normalmente, estas nuevas revisiones o refinamientos tienen relacin con la adicin de funcionalidades al sistema por parte de la organizacin, 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 implantacin, adems de las implicaciones econmicas que pueden tener en el aumento de los requisitos que hay que implementar. El resultado de esta fase tiene una estrecha relacin con la fase de evaluacin final del estudio de requisitos del sistema. Normalmente, de la fase surge la ltima revisin del documento de trabajo con los requisitos del nuevo sistema, acordada y validada por la organizacin y el equipo que ha realizado el estudio de requisitos. 2.3.5. Evaluacin final
La evaluacin final del estudio de requisitos es el segundo punto de control del proyecto, y tiene el objetivo de determinar la viabilidad del proyecto de implantacin 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 relacin con la validacin de los requisitos, ya que el principal documento de trabajo es la ltima definicin de los requisitos de la implantacin del sistema, acordada por la organizacin. Eventualmente, las fases de validacin y de evaluacin final se pueden fusionar desde un punto de vista decisorio sobre la continuacin del proyecto.
FUOC P08/M2104/00604
55
La viabilidad de los requisitos del sistema se evala considerando su adecuacin respecto del sistema actual, la organizacin, y la actuacin estratgica que ha iniciado el proyecto. Con el estudio de requisitos se plasma la primera aproximacin formal al nuevo sistema y las primeras apreciaciones sobre el volumen y el coste de los cambios. En cierta manera, la evaluacin de los requisitos se asimila a la evaluacin del estado actual, presentada en el primer apartado, donde se evala en trminos de economa, tecnologa, funcionalidad y legalidad. Sin embargo, tambin se pueden valorar otros aspectos relacionados con la estrategia de la organizacin, como por ejemplo la capacidad de evolucin de la organizacin, los beneficios intangibles del cambio, la calidad de la gestin o la tica corporativa. La evaluacin de la propuesta de requisitos del nuevo sistema puede generar tres grandes grupos de conclusiones: Elproyectonoesviable. La valoracin de los requisitos del nuevo sistema por parte de la organizacin concluye que la implantacin del nuevo sistema no es viable y el proyecto se aborta. Los motivos para llegar a esta conclusin pueden ser diversos, e incluso, externos al mismo proyecto. Normalmente, esta resolucin puede tener relacin con la economa, la financiacin, la competencia o el abandono de la estrategia que ha iniciado este proyecto. Elproyectoesviableparcialmente. La valoracin de los requisitos del nuevo sistema por parte de la organizacin concluye que el proyecto se llevar a cabo de forma parcial, donde slo algunos elementos del nuevo sistema sern implantados. Normalmente, esta resolucin puede tener relacin con la economa y la financiacin. Hay que tener en cuenta que, en algunos casos, la implantacin parcial se puede realizar de forma progresiva o por etapas10. En estos casos, es importante establecer garantas de cohesin entre las diferentes implantaciones a lo largo del tiempo. Elproyectoesviable. La valoracin de los requisitos del nuevo sistema por parte de la organizacin es favorable y el proyecto contina sin limitaciones o restricciones importantes que afecten a la definicin 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 organizacin. Por otra parte, la decisin de la organizacin respecto de la continuacin del proyecto y sobre el alcance de implantacin del nuevo sistema.
(10)
Algunas organizaciones prefieren repartir la carga de inversin que supone una nueva implantacin en diferentes aos contables.
FUOC P08/M2104/00604
56
2.4. Anlisis de las soluciones en software libre En este apartado se define el anlisis de las soluciones al proyecto de implantacin y se presentan sus principales caractersticas y particularidades. Se detallan las diferentes fases que componen el anlisis, los factores que influyen en su desarrollo, y los resultados que se espera obtener de la etapa.
El anlisis de soluciones es un proceso donde se analiza de forma metdica y rigurosa las diferentes opciones tecnolgicas disponibles segn los requisitos del proyecto.
Los objetivos de este anlisis se centran principalmente en tres aspectos complementarios: Conocimiento del mercado. El anlisis de soluciones permite estudiar y evaluar la situacin del mercado actual en referencia a la definicin, el alcance y los objetivos del proyecto de implantacin. La variedad de soluciones actuales motiva un anlisis en detalle y escrupuloso. Adecuacindelasolucin. El anlisis permite seleccionar las soluciones que mejor se adaptan a la problemtica del proyecto y a la implantacin del sistema. Adems, las propiedades de apertura del cdigo fuente inherentes al software libre permiten el ajuste y adecuacin final de las soluciones seleccionadas en forma de productos derivados. Reduccindelriesgo. El anlisis de soluciones permite reducir el riesgo del proyecto y de la implantacin del sistema, ya que el estudio permite adecuar la solucin y controlar las principales repercusiones de su implantacin. La etapa de anlisis de soluciones en software libre se enmarca en un escenario delimitado fundamentalmente por dos condiciones: Tipologadelproyecto. La tipologa del proyecto, las caractersticas y el mbito del sistema a implantar determinarn el espectro de busca y el anlisis de soluciones posibles, as como la viabilidad de las diferentes propuestas. Anlisisderequisitos. El anlisis de los requisitos del sistema tiene que determinar el comportamiento funcional y operativo de la solucin hacia los objetivos del proyecto.
FUOC P08/M2104/00604
57
Tal como se desprende de los anteriores prrafos, esta etapa parte de los documentos de definicin, objetivos y alcance del proyecto, as como de los requisitos del sistema acordados con la organizacin. Tambin puede resultar interesante el informe de evaluacin de la situacin actual, donde se reflejarn las caractersticas, particularidades y conclusiones de la viabilidad del actual sistema. Todos ellos tienen que ayudar a centrar y focalizar las caractersticas del anlisis. Esta etapa se fundamenta en la fortaleza y diversificacin de la oferta en software libre del mercado actual. La busca y seleccin de soluciones libres que cumplan los requisitos de la implantacin es bsica para el proyecto de implantacin. En este sentido, el anlisis tiene que reflejar las cualidades competitivas del software libre respeto soluciones privativas, considerando especialmente las libertades de uso y adecuacin del cdigo fuente. A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa de anlisis de las soluciones en software libre: la bsqueda de las soluciones, el anlisis y valoracin de los candidatos, y la evaluacin final. 2.4.1. Bsqueda de las soluciones
Esta primera fase de bsqueda pretende identificar soluciones plausibles de ser implantadas en el marco del proyecto. Se trata de realizar una primera seleccin de sistemas cuyo objetivo se aproxime a los objetivos del proyecto. El software libre constituye una opcin vlida y viable para la implantacin de sistemas, permitiendo un amplio abanico de libertades sobre el uso, la explotacin, el acceso y modificacin al cdigo fuente, y el licenciamiento de los derivados. Estas caractersticas no slo permiten su uso libre en organizaciones y particulares, sino tambin permiten la independencia de los proveedores propietarios, el ahorro en licencias y royalties, aprender del cdigo fuente original, controlar la obsolescencia con garantas de mantenimiento, calidad y fiabilidad del producto, o garantizar aspectos de seguridad, privacidad, interoperabilidad y convergencia del software. Histricamente, se pueden destacar dos mbitos principales en la implantacin del software libre: Implantacin en servicios de infraestructura
11 (11)
Desde sus inicios, el software libre ha tenido una relacin muy estrecha con la arquitectura de sistemas y los servicios de red. Actualmente, lidera sobradamente algunos sectores12 ante el software propietario. Implantacin en clientes o usuarios domsticos
13
Por ejemplo, los servidores de una red local forman parte de los servicios de infraestructura bsica de la organizacin.
FUOC P08/M2104/00604
58
Con el paso del tiempo, y gracias a iniciativas de diferente orden, el software libre se ha extendido hacia el entorno de usuario final, habiendo iniciado una nueva trayectoria ante los estndares de facto en el entorno domstico.
Por ejemplo, la implantacin de Apache Web Server en servidores web es superior respecto de otros entornos.
(13)
Por ejemplo, la distribucin Ubuntu compete directamente contra el sistema operativos de Microsoft, rompiendo muchos mitos sobre la dificultad de la instalacin, la gestin 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 mayora de proyectos importantes disponen de portales en Internet, que permiten el conocimiento, la difusin, la descarga y la colaboracin con el proyecto . Sin embargo, tambin existen depsitos pblicos15 que permiten la creacin, el desarrollo y la colaboracin en nuevos proyectos relacionados con el software libre, as como la descarga de los productos resultantes. Los depsitos actan en muchos casos de plataforma de lanzamiento para proyectos comunitarios. Hay que considerar que es posible que no exista una solucin nica para el proyecto de implantacin, ya sea por alcance o por especializacin de los objetivos. En estos casos, hay que categorizar la busca de soluciones en tipologas ms genricas, de tal modo que diversos sistemas especializados puedan cooperar para dar una solucin conjunta a los requisitos del proyecto16.
(16) 14
(14)
Por ejemplo, la distribucin Ubuntu (www.ubuntu.com), la suite ofimtica OpenOffice.org (www.openoffice.org) o la suite de navegacin Mozilla (www.mozilla.org).
(15)
Por ejemplo, SourceForge.net (sourceforge.net).
Por ejemplo, si se busca una solucin para la gestin de una base de datos va web, puede resultar factible buscar separadamente un sistema operativo, un servidor web, un gestor de bases de datos y una herramienta de programacin que puedan cooperar para ofrecer las funcionalidades exigidas. ste es el caso del entorno LAMP (Linux, Apache, MySQL i PHP), de gran difusin actualmente.
De la bsqueda de soluciones se tiene que obtener un documento con los resultados de la investigacin. Este documento tendra que contener los siguientes aspectos: Definicineidentificacindelabsquedadesoluciones. Establece las caractersticas que han guiado la bsqueda, denotando la relacin con la definicin del proyecto, objetivos y alcance, as como con la definicin 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 bsqueda, estableciendo en cada caso una breve definicin de la solucin y la relacin con los objetivos del proyecto. Fichatcnicadesoluciones. La ficha tcnica de cada solucin tiene que permitir conocer las principales caractersticas del sistema, como por ejemplo la definicin del proyecto, los depsitos donde se encuentra, el segui-
FUOC P08/M2104/00604
59
miento y mantenimiento del producto, los idiomas que soporta, la colaboracin comunitaria, la licencia final y otros requisitos inherentes al producto, como la ergonoma de uso, los requisitos de ejecucin y las principales funcionalidades. En caso de que no existan soluciones nicas para la problemtica que presenta el proyecto y sea necesario la categorizacin en diferentes soluciones individuales, el documento se podr estructurar en categoras por tipologa (por ejemplo, sistemas operativos o suites de ofimtica) o por funcin (por ejemplo, un servidor de base de datos con interfaz web de acceso y programacin). 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 caractersticas, ventajas e inconvenientes inherentes a su adopcin. 2.4.2. Anlisis y valoracin de los candidatos
La fase de anlisis y valoracin de los candidatos pretende identificar las soluciones ms adecuadas al proyecto y a la organizacin, pero tambin a las particularidades del desarrollo, la implantacin y la migracin. Esta fase parte del documento de la fase anterior, en el cual se listan las soluciones actuales ms indicadas para el proyecto y se detallan las principales caractersticas. Se trata de seleccionar de manera metdica y rigurosa a los mejores candidatos para la implantacin de entre las diferentes alternativas identificadas. Normalmente, se analiza, se pondera y se evala un conjunto determinado de parmetros tecnolgicos relacionados directamente con el proyecto, la organizacin y el proceso de implantacin. La valoracin individual llevar a establecer una clasificacin ordenada que determinar la adecuacin de cada solucin al proyecto de implantacin. De manera general, se pueden considerar los siguientes parmetros para la evaluacin y valoracin de una solucin: Proyectoyorganizacin. Hay que valorar la adecuacin a los objetivos del proyecto, la organizacin, la definicin de los mtodos y procedimientos, la tica y estndares histricos de la organizacin y la actuacin estratgica que ha emprendido el proyecto. Sistemaeinteroperabilidad. Hay que valorar la adecuacin a las necesidades del sistema y que garantice el funcionamiento con la dotacin de recursos de hardware, software y red actual o futura, la factibilidad de los mtodos y procedimientos, la implementacin de la actuacin estratgica,
FUOC P08/M2104/00604
60
la interoperabilidad con otros sistemas existentes y estndares de la organizacin y las posibilidades de ampliacin y evolucin futura. Funcionalidadyergonoma. Hay que valorar la adecuacin a las necesidades funcionales y operativas del proyecto y de la organizacin y que garantice la ergonoma de su utilizacin, implemente los mtodos y procedimientos con garantas de funcionamiento y responda a las esperanzas de los usuarios y de la organizacin. Eficiencia y rendimiento. Hay que valorar que garantice un funcionamiento 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 evolucin. Eficaciayfiabilidad. 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 mantenga tambin el equilibrio entre recursos y el cumplimiento a lo largo del tiempo y que permita la evolucin. Implantacinymigracin. Hace falta valorar la adecuacin al proceso de implantacin del sistema y que permita la migracin eficiente y eficaz a partir de un sistema anterior, minimice las consecuencias de impacto en el funcionamiento habitual de la organizacin y garantice herramientas de soporte, formacin y adaptacin de los usuarios y de los otros sistemas existentes. Mantenimientoygestin. Hay que valorar que garantice que el sistema disponga de herramientas de gestin y configuracin adecuadas a los objetivos del proyecto, minimice las operaciones de mantenimiento fsicas y lgicas, garantice el equilibrio entre funcionamiento y mantenimiento a lo largo del tiempo, y permita la evolucin. Soporteycompromiso. Hay que valorar que garantice el soporte y seguimiento de sus creadores con el sistema y con sus usuarios y que ayude al compromiso de la comunidad en la evolucin y mejora futura y, en general, a todos aquellos aspectos que puedan suponer la obsolescencia del sistema y la resolucin de problemas. Licencias. Hay que valorar que garantice el cumplimiento de la legalidad vigente, establezca el escenario de uso y explotacin, permita la distincin clara y efectiva de las actuaciones que se pueden llevar a cabo con el sistema y especifique las licencias de los eventuales productos derivados. Economa. Hay que valorar la adecuacin a la economa de la organizacin, a la financiacin prevista del proyecto, a los costes de gestin, man-
FUOC P08/M2104/00604
61
tenimiento y funcionamiento eficiente y eficaz a lo largo de la vida prevista del sistema y tambin a los costes de formacin y educacin de los usuarios del sistema. Tal como se desprende de la lista anterior, los parmetros buscan la valoracin de los candidatos en diferentes mbitos (tecnolgico, estratgico, operativo, econmico, etc.), con el objetivo de profundizar, analizar y valorar el impacto de la eventual implantacin en la organizacin. El resultado de esta fase es un documento que clasifica y pondera de manera numrica los diferentes candidatos (eventualmente por categoras) y ordena las soluciones por grado de adecuacin al proyecto y a la organizacin. Sin embargo, es posible que se produzcan empates tcnicos entre diferentes soluciones, es decir, que haga falta un estudio adicional entre alternativas que, a pesar de diferir en sus caractersticas, presentan adecuaciones similares para el proyecto. En estos casos, puede ser til implementar una tabla DAFO de cada solucin, con el objetivo de hacer surgir diferencias que puedan ayudar a la eleccin final. 2.4.3. Evaluacin final
La evaluacin final del anlisis de soluciones en software libre es el tercer punto de control del proyecto y tiene el objetivo de determinar el desarrollo del proyecto de implantacin, es decir, la forma que tomar el proyecto y su implementacin final. Esta fase parte de los documentos de la fase anterior, que contienen una clasificacin de las soluciones existentes segn su adecuacin al proyecto, as como las fichas tcnicas y/o tablas DAFO que las analizan en profundidad. Esta fase trata de cumplir dos objetivos principales: Seleccinfinaldecandidatos. Aunque la fase anterior ya propone indirectamente las soluciones ms adaptadas al proyecto y a la implantacin (mediante la puntuacin y la clasificacin), puede convenir evaluar adicionalmente la integracin global de todas las soluciones. Desarrollodelproyecto. La seleccin de las soluciones que satisfacen los requisitos del proyecto comportarn consecuencias directas en su desarrollo, por ejemplo en su coste temporal y econmico. Es importante destacar que los componentes del sistema no estarn desacoplados entre s, por lo que se debern hallar las mejores soluciones que generen un sistema estable y operativo, adems de cumplir con los requisitos del proyecto.
FUOC P08/M2104/00604
62
En algunos casos, puede resultar til realizar pruebas de integracin que permitan determinar la calidad y rendimiento de la cohesin de los diferentes elementos, ya que la integracin de diversas soluciones altamente puntuadas en sus respectivas categoras no garantiza que el comportamiento global est al mismo nivel17. Con respecto al desarrollo del proyecto, la eleccin de las soluciones comporta ajustes en el proyecto, especialmente en la fase de desarrollo. Globalmente, se pueden considerar tres tipos diferentes de implantacin: Implantacindirecta. Las soluciones que ms se ajustan a las necesidades del proyecto y de la organizacin se pueden implantar de manera directa, ya sea porque son de uso general o porque los objetivos del proyecto responden a las necesidades especficas de un colectivo grande. En cualquier caso, las diferencias entre los requerimientos del proyecto y las funcionalidades de la solucin no son determinantes para rechazar la adopcin. Evolucindelasolucin. Las soluciones que ms se ajustan a los requerimientos del proyecto y de la organizacin nicamente presentan diferencias significativas en puntos concretos. Su adopcin requiere una evolucin del cdigo fuente para ajustar las carencias que pueda tener la solucin original ante las incidencias del sistema. Gracias a las libertades que ofrece el software libre, sta es una opcin vlida y viable en la prctica, mientras que la alternativa en software propietario posiblemente requirira un desarrollo completamente nuevo, con las implicaciones econmicas que ello comporta. Desarrollonuevo. No existen soluciones que se ajusten con suficiencia a las incidencias del proyecto y de la organizacin, por lo que ser necesario un desarrollo completamente nuevo con el fin de solucionar la problemtica. Estos casos se pueden dar en sistemas con requerimientos muy especializados, como la robtica. En casos extremos, es posible que tampoco existan soluciones de propiedad en los canales habituales de comercializacin. En cualquier caso, la libertad de estudiar, analizar y reutilizar el cdigo fuente del software libre permite mejorar la calidad, eficiencia y eficacia del nuevo desarrollo y abaratar los costes asociados. La evaluacin de las soluciones en software libre puede conducir a tres grandes tipos de conclusiones: Proyectoviabledeimplantacindirecta. El proyecto es viable y los requisitos de la implantacin se pueden resolver con soluciones existentes.
Por ejemplo, si el conector de los dos sistemas no es eficiente o est limitado por la compatibilidad con otros sistemas.
Soluciones de implantacin directa Ejemplos de soluciones de implantacin directa pueden ser sistemas operativos, paquetes de ofimtica, clientes de correo electrnico o navegadores web.
(18)
Por ejemplo, la sustitucin del software MS Word por OpenOffice.org, en el que las diferencias funcionales se pueden suplir con la formacin de los usuarios.
FUOC P08/M2104/00604
63
Las eventuales diferencias entre las soluciones que se tienen que implantar y las incidencias del proyecto no son insalvables18. Proyectoviableconcondiciones. El proyecto es viable, pero los requisitos de la implantacin requiere emprender un proceso de creacin o adaptacin de soluciones. Las implicaciones temporales y econmicas vendrn dadas por el alcance del proceso, que ser mximo cuando sea necesario un desarrollo completamente nuevo. Proyectoinviable. Aunque en esta etapa no es habitual abortar el proyecto, se pueden dar casos en que la organizacin no quiera continuar con l. Por ejemplo, por la falta de financiacin para afrontar un desarrollo concreto o cambios en la estrategia de la organizacin. El resultado de esta etapa es doble: Por una parte, obtendremos las soluciones en software libre ms adaptadas a los requerimientos del proyecto y de la organizacin. Por otra parte, obtendremos una valoracin preliminar de los costes relacionados con la etapa de desarrollo del proyecto (implantacin directa o necesidad de un desarrollo adicional).
2.5. Formalizacin de la propuesta En este apartado se define la formalizacin de la propuesta del proyecto de implantacin y se presentan las principales caractersticas y particularidades. Se detallan las diferentes fases que componen el proceso, los principales factores que influyen en su desarrollo y los resultados que se pueden obtener de la etapa.
La formalizacin de la propuesta es la etapa del proyecto donde se concretan, se especifican y se enlazan todos los resultados obtenidos en las primeras fases metodolgicas del proyecto llamadas etapas de diseo, con el objetivo de proponer una solucin formal a la problemtica de implantacin de sistemas de la organizacin.
Los objetivos especficos de esta etapa se centran principalmente en tres aspectos: Caracterizacin del proyecto. La formalizacin de la propuesta rene, clarifica y relaciona todos los resultados de las primeras etapas del diseo de la implantacin de sistemas. El resultado de esta etapa tiene que servir
FUOC P08/M2104/00604
64
de gua para el desarrollo posterior de la implantacin, por lo cual se hace notar su importancia dentro del proyecto. Validacinporpartedelaorganizacin. La formalizacin de la propuesta tambin sirve para presentar y evaluar el proyecto de implantacin por parte de la organizacin. La valoracin que resulta concreta el futuro del proyecto, su viabilidad y su desarrollo y ejecucin. Reduccindelriesgo. La formalizacin de la propuesta permite reducir el riesgo del proyecto y de la implantacin del sistema y delimita el escenario de evolucin del proyecto gracias a la concrecin de las soluciones y del desarrollo de la implantacin. Esta etapa guarda relacin con la gestin funcional del proyecto porque permite concretar aspectos de la planificacin del proyecto como la gestin de los tiempos, los recursos y el coste del proyecto, considerando la informacin que se obtiene a partir de los resultados de las etapas anteriores. Globalmente, la propuesta tiene que dar respuesta a dos aspectos principales: Aspectosmetodolgicos. Los aspectos metodolgicos hacen referencia a los resultados de las etapas de anlisis y diseo de la implantacin de sistemas, vistas en esta unidad. Ms concretamente, el anlisis del sistema actual, el anlisis de requerimientos y el anlisis de soluciones en software libre. El objetivo es plasmar las caractersticas del sistema que se tiene que implantar como resultado de un proceso metdico y riguroso. Aspectosdegestin. Los aspectos de gestin hacen referencia a las particularidades de funcionamiento y ejecucin del proyecto, como la planificacin temporal, la econmica o la relativa a los recursos humanos que harn falta para llevar a trmino el proyecto. El objetivo es plasmar los parmetros de ejecucin del proyecto, ofreciendo una visin clara de los requisitos necesarios con el fin de alcanzar los objetivos. De los anteriores prrafos podemos concluir la importancia de la comunicacin y la colaboracin con la organizacin, con el objetivo de transmitir correctamente toda la informacin relevante del proyecto. Globalmente, se pueden identificar dos aspectos principales de la informacin que hay que transmitir: Elproyecto. La comprensin del proyecto, de los resultados obtenidos en el anlisis y de la solucin ms adecuada a las caractersticas del proyecto. Es importante que quede clara la relacin entre las propuestas del proyecto y la actuacin estratgica que persigue la organizacin. Elsoftwarelibre. La comprensin de la utilizacin del software libre, el modelo filosfico en el cual se sustenta y las caractersticas de las licencias,
Ved tambin Consultad stos y otros aspectos de la gestin de proyectos en el apartado de "Gestin de proyectos en software libre" de la primera unidad.
FUOC P08/M2104/00604
65
as como las particularidades de las soluciones propuestas y los beneficios que obtiene la organizacin. A grandes rasgos, se pueden considerar cuatro grandes fases dentro de la formalizacin de la propuesta: la preparacin, el diseo, la presentacin y la evaluacin final. 2.5.1. Preparacin de la propuesta
Esta primera fase de formalizacin de la propuesta pretende recuperar todas las informaciones plausibles de ser incorporadas en la propuesta de solucin. Se trata de obtener los documentos de resultado de las diferentes etapas de estudio y anlisis, as como de la planificacin del proyecto. Uno de los principales objetivos de esta primera fase es generar resultados avanzados a partir de los datos iniciales. Es decir, crear resmenes, esquemas, tablas, diagramas o grficos que permitan clarificar los conceptos de los documentos tcnicos que se han desarrollado a lo largo del proyecto. Otro resultado que se obtiene de esta primera fase es la actualizacin de la planificacin del proyecto a partir de la informacin contenida en los diferentes documentos de anlisis. Normalmente, los aspectos ms importantes para la organizacin son: Solucinaimplantar. Es importante la definicin de la solucin que se quiere implantar, los objetivos y el alcance del proyecto, las incidencias estratgicas a las que da solucin y los sistemas que sern implantados. Costetemporal. El coste temporal tiene relacin con la planificacin temporal de los recursos y de la propia implantacin o migracin. Costeeconmico. El coste econmico tiene relacin con la repercusin econmica que resulta de implantar el sistema en la organizacin (material, recursos, tiempo, formacin, etc.) y de la gestin del proyecto (equipo de gestin del proyecto). Hay que tener presente que debe valorarse el coste econmico del proyecto desde sus inicios19. Eventualmente, tambin puede resultar til preparar los siguientes aspectos: Buscar mitos histricos 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 cambio sentacin.
20 (20)
Ved tambin Consultad el apartado "Gestin del tiempo" para conocer ms aspectos del coste temporal del proyecto.
Ved tambin Consultad el apartado "Gestin del coste" con el fin de conocer ms aspectos del coste econmico del proyecto.
(19)
Tal como se desprende del apartado "Recursos de un proyecto de implantacin de sistemas", el proyecto se inicia cuando se dota de recursos por primera vez. En ingls FUD (fear, uncertainty and doubt).
que se puedan observar en su pre-
FUOC P08/M2104/00604
66
Obtener y presentar informacin de tipologas de licencia en software libre, con el objetivo de desmitificar algunas asunciones y transmitir con fundamentos la filosofa libre y su relacin con la solucin propuesta.
Crear tablas DAFO para representar y justificar situaciones en que ha sido necesario tomar decisiones a partir del estudio y la evaluacin 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 tcnicos de anlisis de las etapas de diseo, as como diversos resultados avanzados e informacin relacionada con el proyecto y el software libre. Por otra parte, una actualizacin de la planificacin de la gestin del proyecto, que incluir todos los aspectos derivados de las etapas de anlisis y diseo, que modelan la continuacin del proyecto.
2.5.2.
Diseo de la propuesta
La fase de diseo de la propuesta pretende confeccionar todos aquellos documentos y presentaciones que deben presentarse a la organizacin y que resumen el trabajo realizado en las etapas de estudio y anlisis del proyecto de implantacin de sistemas. Esta fase parte de los documentos de la fase anterior, con referencias a documentos tcnicos, informacin relacionada con el proyecto y con el software libre, resultados avanzados y actualizacin de la planificacin temporal y econmica. Se trata de estructurar, organizar y presentar toda la informacin disponible a fin de que sirva de gua para el posterior desarrollo del proyecto. Globalmente, se pueden llegar a generar dos grandes tipos de documentos diferentes: Informesyplanificaciones: son documentos que presentan los resultados de un estudio profundizado. Su objetivo es presentar los contenidos de manera estructurada y metdica, con precisin, orden y rigor, a fin de que sean utilizados como gua o manual del proyecto. Presentaciones: son documentos que muestran el estudio en lneas generales. Su objetivo es presentar los principales conceptos del estudio de manera ordenada, sinttica y grfica, a fin de que sean utilizados como resumen del proyecto.
FUOC P08/M2104/00604
67
Los informes tienen que presentarse editados y compaginados, utilizando un lenguaje formal y riguroso. Normalmente, un informe contiene los siguientes elementos: Resumenejecutivo: es un resumen breve, que ubica el proyecto de implantacin de sistemas y su contenido en el tiempo, en el espacio, en los objetivos y en las soluciones. Introduccin: presenta la situacin estratgica de la organizacin y la necesidad de emprender un proyecto de implantacin de sistemas en unas circunstancias concretas. Anlisisdelasituacinactual: tiene que presentar un resumen del estudio, el anlisis y las conclusiones del sistema actual de la organizacin en relacin a su estrategia. Definicin,objetivosyalcance: se presenta el proyecto de implantacin de sistemas, los conceptos generales de la solucin que se propone, la justificacin del uso del software libre y su adecuacin a la estrategia de la organizacin. Arquitecturadelsistema,infraestructuraytecnologa: presenta la arquitectura general y funcional del sistema, la infraestructura que requiere, la tecnologa y los estndares que utiliza, as como las licencias finales. Eventualmente se pueden presentar pruebas de integracin de los diferentes elementos. Recursos humanos y materiales: se presentan los recursos humanos y materiales necesarios para el funcionamiento habitual del sistema dentro de la organizacin. Implantacinymantenimiento: presenta la metodologa de implantacin que se seguir, las caractersticas de la migracin, la formacin de los usuarios, la adaptacin de la organizacin y el mantenimiento necesario de la instalacin a lo largo del tiempo (normalmente, a un plazo de cinco aos). Planificacintemporal: detalla el seguimiento y la relacin de las etapas del proyecto a lo largo del tiempo, con la cosideracin de los recursos asignados en cada momento. Normalmente, tambin se presenta un grfico donde se representan las etapas en funcin del tiempo. Planificacineconmica: presenta la valoracin del coste de llevar a cabo el proyecto, desglosando las diferentes partidas que componen el coste de la implantacin (por ejemplo, coste de la gestin de los proyectos, recursos
FUOC P08/M2104/00604
68
humanos necesarios, gastos de material, desarrollo y ajuste de software, instalacin de infraestructura). Sinergiasconlacomunidaddesoftwarelibreyconotrosproyectosu organismos: eventualmente, y segn las caractersticas de la organizacin, se incluye un apartado que explica la relacin de las soluciones utilizadas con el mundo de la filosofa libre, el aprovechamiento de otros proyectos similares y la relacin con otros organismos o con la comunidad de software libre. Conclusiones: hay que poner nfasis en las caractersticas del proyecto que solucionan las necesidades estratgicas de la organizacin y los beneficios que se obtienen del uso del software libre. Anexostcnicos: pueden ser tiles para el desarrollo posterior del proyecto. Por ejemplo, el anlisis de los requerimientos del sistema. De esta fase se obtienen dos documentos: El informe o plan de proyecto, que se presentar como documentacin tcnica del proyecto. La presentacin, que servir a la reunin ejecutiva de la fase siguiente.
2.5.3.
Presentacin de la propuesta
En esta fase se presenta la propuesta a la organizacin, normalmente enmarcada dentro de una reunin ejecutiva con su rgano directivo. El objetivo consiste en poner en conocimiento de la organizacin los resultados finales de las etapas de anlisis, a fin de que puedan valorar la propuesta de solucin y el seguimiento del proyecto, as como evaluar su continuidad. Normalmente, esta fase se implementa presentando todos los aspectos del proyecto de manera grfica y resumida, utilizando el documento de presentacin de la fase anterior. De manera adicional a la presentacin, se hace entrega del plan de proyecto con los resultados de las etapas de diseo. En esta fase es de especial importancia poner de relieve la comunicacin y la transmisin de la informacin, destacando la relacin de la propuesta con los objetivos estratgicos de la organizacin. Aunque no es habitual, eventualmente se puede pedir la reformulacin de algunos aspectos de la propuesta, que, en cualquier caso, tendran que ser de poco alcance cuantitativo y cualitativo.
FUOC P08/M2104/00604
69
Es posible que la comisin que tiene que decidir la implantacin del sistema muestre reticencias al uso del software libre, por lo cual puede convenir justificar la propuesta desmitificando algunas ideas preconcebidas, presentando las ventajas e inconvenientes de su uso o, incluso, la filosofa libre en general y los modelos de licencia. Puede resultar til el documento realizado en la fase de diseo de la propuesta sobre temas relacionados con el proyecto y el software libre. Esta fase tiene especial relacin con la fase siguiente, de evaluacin final, ya que a menudo las reuniones de presentacin son decisorias con respecto a la continuacin del proyecto. 2.5.4. Evaluacin final
La fase de evaluacin final de la formalizacin de la propuesta es el cuarto punto de control del proyecto y tiene como objetivo valorar el trabajo realizado en las etapas de diseo de la implantacin, as como la propuesta de solucin al proyecto. Tambin tiene el objetivo de resolver la viabilidad y continuidad del proyecto para las etapas de desarrollo e implantacin del sistema. Esta fase tiene una estrecha relacin con la anterior, ya que la presentacin del plan de proyecto y el intercambio de informacin entre el equipo que ha realizado el diseo y la organizacin es fundamental para considerar todas las implicaciones de la solucin presentada. Eventualmente, las fases de presentacin y validacin de la propuesta se podran fusionar desde el punto de vista decisorio sobre la continuacin del proyecto. La importancia de este punto de control es doble: Por una parte, porque con la formalizacin de una propuesta se cierra el ciclo terico y conceptual de anlisis y diseo del sistema y del proyecto de implantacin que lleva asociado. Las etapas siguientes sern principalmente prcticas. Por otra parte, porque la organizacin determinar si el proyecto se completar finalmente y dar respuesta a la actuacin estratgica que lo inici, con la implantacin del conjunto de cambios que se consideran en la propuesta. En este sentido, y tal como ya se ha comentado en anteriores apartados, la organizacin tiene que valorar los aspectos del proyecto que considere adecuados a su estrategia; por ejemplo, las caractersticas de la solucin que se quiere implementar, el coste temporal con el fin de realizar la implantacin y el coste econmico del proyecto y de la implantacin del sistema.
FUOC P08/M2104/00604
70
Tambin puede ser un buen momento para analizar, valorar y adecuar algunos detalles inherentes a la implantacin del sistema en la organizacin, considerando y concretando algunos aspectos de la gestin del cambio, el calendario de la implantacin, las pruebas piloto o la formacin de los usuarios. La evaluacin de la propuesta por parte de la organizacin puede acabar en tres grandes tipos de decisiones: Proyectoviable. La organizacin acepta la solucin propuesta sin cambios importantes en sus especificaciones. Los eventuales ajustes pueden hacer referencia al calendario de la implantacin o la inclusin de algunas partidas econmicas, por ejemplo. Proyectoviableconcondiciones. La organizacin considera que se necesitan ajustes en la propuesta de solucin. Los cambios pueden ser de mayor o menor consideracin, pero en cualquier caso habr que rehacer una parte de la propuesta si se quiere que el proyecto siga adelante. Estos cambios pueden tener relacin con las herramientas implantadas o con la ejecucin parcial del proyecto, por ejemplo. Proyectonoviable. La organizacin considera que el proyecto no es viable y se aborta la implantacin del sistema. Aunque no es habitual que pase en esta etapa del proyecto, un cambio drstico en la estrategia de la organizacin o la incapacidad para asumir econmicamente la finalizacin del proyecto pueden ser causas plausibles del aborto prematuro de la implantacin. El resultado de esta etapa es doble: Por una parte, se obtiene el plan de proyecto, acordado y validado con la organizacin. Por otra parte, se obtiene la decisin sobre la continuacin e implementacin del proyecto.
2.6. Desarrollo En este apartado se define la etapa de desarrollo del proyecto de implantacin y se presentan las principales caractersticas 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
El desarrollo del sistema es la etapa en que se implementan las soluciones que se especifican en el plan de proyecto, as como todos los requisitos relacionados con su puesta en marcha. El objetivo principal es adecuar, recolectar y producir todos los elementos necesarios con el fin de realizar la implantacin con el mximo de garantas de eficiencia y eficacia, minimizando el tiempo de intervencin.
Esta etapa parte de los documentos de la etapa anterior, principalmente el plan de proyecto y el anlisis 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 especficos de esta etapa se centran principalmente en dos aspectos: Implementacindelasolucin. El desarrollo pretende implementar la solucin que determina el plan de proyecto y el estudio de los requerimientos, independientemente de la forma que tome el tipo de desarrollo. Reduccin del riesgo. El desarrollo tambin pretende reducir el riesgo global del proyecto, preparando, concretando y construyendo la solucin sin afectar directamente al funcionamiento de la organizacin. Globalmente, el desarrollo tiene que dar respuesta a dos aspectos principales: Aspectosmetodolgicos. Los aspectos metodolgicos hacen referencia a la tipologa del proyecto, por lo cual la etapa de desarrollo tiene una relacin directa con el objeto de la implantacin. Es decir, la metodologa de desarrollo que habr que aplicar depender del objetivo del proyecto. Aspectosdegestin. Los aspectos de gestin hacen referencia a los implicados 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 considerar un desarrollo interno (insourcing) o externo (outsourcing). A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa de desarrollo: la dotacin de recursos, la configuracin o desarrollo de software y la evaluacin final, aunque la existencia individual de estas etapas depende en gran medida de la tipologa del proyecto.
Ved tambin En el apartado "Verificacin de los requerimientos" de este mdulo se han presentado tres tipologas de proyecto: la implantacin directa, la evolucin de herramientas existentes y el desarrollo de una nueva solucin.
Ved tambin Consultad el apartado 1.2.2 "Clasificacin por objetivo de los proyectos" con el fin de conocer las diferentes tipologas de proyectos en funcin del objetivo.
Ved tambin Consultad el apartado "Recursos de un proyecto de implantacin de sistemas" de la primera unidad con el fin de conocer ms aspectos del desarrollo interno y externo.
FUOC P08/M2104/00604
72
Hay que precisar que las fases de dotacin de recursos y desarrollo de software se pueden ejecutar de manera simultnea en el tiempo, en funcin de la tipologa del proyecto. Tambin es posible que la superposicin temporal sea slo parcial, a causa de diferencias en el calendario de entrega de los diferentes recursos, por ejemplo. Tambin hace falta tener en cuenta que la etapa de desarrollo guarda una estrecha relacin con la siguiente, la de implantacin o migracin del sistema. En este caso, eventualmente tambin se puede producir la superposicin o simultaneidad temporal de algunas tareas con el fin de reducir el calendario del proyecto, aunque puede tener consecuencias econmicas que hay que valorar, como la necesidad de ms recursos humanos y materiales, por ejemplo. 2.6.1. Dotacin de recursos
Esta primera fase de dotacin de recursos pretende seleccionar y adquirir todos los recursos necesarios para la implantacin del sistema en la organizacin. Se trata de obtener todos aquellos elementos que tienen una relacin de prerrequisito directa para la implantacin y explotacin del nuevo sistema. Uno de los principales objetivos de esta primera fase es dotar la organizacin 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 operativo21. En este sentido, si el proyecto incluye la migracin total o parcial del sistema, puede resultar eficiente enlazar esta fase con la de planificacin de la migracin. Normalmente, la dotacin de recursos materiales se adjudica evaluando las caractersticas de las propuestas de los proveedores segn un conjunto de bases especfico. Este conjunto de bases tiene que crearse a partir de los requerimientos del sistema, con el fin de poder garantizar la adecuacin y la integracin con el resto del proyecto. La evaluacin de las diferentes propuestas es particular en relacin con el proyecto, el sistema y la organizacin. A grandes rasgos, se pueden valorar los siguientes aspectos: Sistemaeinteroperabilidad: hay que valorar cada elemento en s mismo, su adecuacin e integracin en el sistema, en el proyecto y en la organizacin. Funcionalidadyergonoma: hay que valorar la facilidad de manipulacin y configuracin del elemento, as como de los conocimientos necesarios para la puesta a punto y su utilizacin cotidiana.
(21)
Como, por ejemplo, la instalacin de una red de rea local, la habilitacin de un local tcnico o la compra de conmutadores, ordenadores y servidores.
Ved tambin Consultad los apartados "Estrategias de migracin", "Inventario de hardware y software" y "Diagrama de red y de estructura" con el fin de conocer ms aspectos de la planificacin de la migracin.
FUOC P08/M2104/00604
73
Eficiencia y rendimiento: hay que valorar el rendimiento funcional y operativo en relacin a las necesidades del sistema.
Eficaciayfiabilidad: hay que valorar la fiabilidad y la consecucin de los objetivos en relacin a los requerimientos del sistema.
Implantacinymigracin: hay que valorar la facilidad para implantar el elemento en el entorno de la organizacin y las herramientas que incorpora para migrar con respecto a la solucin actual.
Mantenimiento,soporteygaranta: hay que valorar las necesidades para el funcionamiento y mantenimiento del elemento, as como el soporte y las garantas que ofrecen los proveedores.
Economa: hay que valorar la relacin entre el coste del elemento y los resultados que ofrece, las ventajas e inconvenientes del impacto en el funcionamiento de la organizacin.
Por otra parte, la implantacin del proyecto tambin puede requerir la dotacin de recursos humanos en la organizacin, ya sea para la manipulacin directa o indirecta del sistema. Hay que destacar que el proyecto surge de una actuacin estratgica de la organizacin y que, por lo tanto, es posible que el cambio de mtodos y procedimientos implique una reestructuracin del personal implicado. En este sentido, el caso extremo correspondera a una organizacin de nueva creacin, o a una organizacin ya creada pero que no disponga de ningn soporte informtico para su funcionamiento. La demanda de perfiles tecnolgicos ira en consonancia con el grado de implantacin tecnolgica, la tipologa del proyecto y las caractersticas de la organizacin. De todos modos, la seleccin de los recursos humanos tendra que integrarse en la metodologa habitual de seleccin que utiliza la organizacin, pero habr que destacar la necesidad de adecuar el perfil del candidato a los requisitos tecnolgicos del sistema y de la nueva estrategia de la organizacin. 2.6.2. Configuracin y/o desarrollo de software
La fase de desarrollo de software pretende implementar todos los ajustes que requiere la solucin en software libre con el fin de adecuarse al plan de proyecto. Tambin se puede incluir en esta etapa el desarrollo de herramientas que puedan ayudar a la conversin de datos o ficheros en la migracin del sistema.
FUOC P08/M2104/00604
74
El principal objetivo de esta fase es garantizar la idoneidad de la solucin en software libre a los requisitos del proyecto, con el ajuste y codificacin de todos los cambios que sean necesarios, aprovechando la apertura del cdigo 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: Implantacindirecta. En el caso de la implantacin directa de software, el escenario de desarrollo se limita al eventual ajuste de los ficheros de configuracin o parmetros del software. Por ejemplo, la configuracin del sistema operativo (idioma, acceso a la red, etc.) o parmetros de herramientas de ofimtica (plantillas, idioma, etc.). Este caso supone una inversin temporal y econmica nfima con respecto a los otros dos casos. Evolucindelsoftware. La evolucin del software considera la ampliacin o adecuacin del cdigo fuente de una o ms soluciones de software libre, con el objetivo de ajustar su funcionamiento al de la organizacin. La importancia de los resultados incide en la necesidad de proceder con el rigor habitual de la ingeniera del software, estableciendo un ciclo de vida adecuado para cada modificacin; eventualmente, de reingeniera del software. Por ejemplo, la introduccin de clculos adicionales en el software de gestin contable o la modificacin del gestor de descargas de un navegador web. Desarrollonuevo. El caso del desarrollo de cdigo nuevo considera que no existe ninguna solucin adecuada a las necesidades especficas de la organizacin. Sin embargo, puede resultar til estudiar y reutilizar el cdigo fuente de aplicaciones abiertas con el fin de ganar tiempo y fiabilidad. El desarrollo nuevo es el ms laborioso en trminos de coste temporal y econmico. Estas implicaciones inciden en la necesidad de proceder segn metodologas de ingeniera del software adecuadas al proyecto. Por ejemplo, la creacin de software de diseo industrial o arquitectnico o de control electrnico 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 oportunos, evaluando el seguimiento y los resultados segn la metodologa ms adecuada. Independientemente del formato de desarrollo, es aconsejable realizar en esta fase la documentacin del proceso de adecuacin del software, con la lista y descripcin de todos los detalles que han estado sujetos a modificaciones,
Ved tambin Podis ampliar los conocimientos metodolgicos para la produccin de software libre en la asignatura de "Ingeniera del software en entornos de software libre".
FUOC P08/M2104/00604
75
con el mismo rigor que en desarrollos nuevos. En estas circunstancias hay que tener presente la licencia final de la solucin que se evoluciona, ya que normalmente la libertad del cdigo fuente se hereda de la solucin original. En esta fase tambin puede convenir desarrollar los materiales de formacin 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 necesarios para su realizacin. En estos casos, tambin hay que tener en cuenta las caractersticas de las licencias de los manuales que se pretende modificar.
Manuales de soporte Las preguntas ms frecuentes (PMF, en ingls FAQ, frequently asked questions) o los habituales manuales de resolucin de tareas concretas (how to en ingls), que a pesar de tener un marcado aspecto tcnico, pueden ser de gran ayuda.
2.6.3.
Evaluacin final
La fase de evaluacin 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. Tambin tiene el objetivo de reducir el riesgo global del proyecto, mediante la validacin de la viabilidad y adecuacin del desarrollo a la estrategia de la organizacin. Normalmente, la evaluacin de esta etapa depende de la tipologa del propio desarrollo: Recursos,instalacioneseinfraestructuras: se valoran segn el cumplimiento de los objetivos con respecto al diseo y la propuesta del proveedor. Hay que sealar la importancia de los plazos de entrega y su repercusin en la planificacin temporal de otras etapas. Implantacindirectadesoftware: se valora el cumplimiento de los objetivos de los ajustes de configuracin y la operativa prevista. La evaluacin principal se considera sobre las pruebas de funcionamiento. Evolucinodesarrollodesoftware: la complejidad de la valoracin es proporcional a la magnitud de los cambios introducidos. Normalmente, se considera la valoracin que resulta del proceso de ingeniera del software. Esta fase tiene una estrecha relacin con la implantacin y la migracin del sistema, ya que en funcin del tipo de proyecto, se pueden implantar las soluciones a medida que finalice su desarrollo. Eventualmente, tambin puede tener relacin con la formacin de los usuarios y las pruebas piloto, ya que puede ser til conocer las apreciaciones de los usuarios con el fin de perfeccionar algunos detalles del desarrollo22.
(22)
Como, por ejemplo, la interfaz grfica, la respuesta del sistema o las caractersticas de los procedimientos que implementa el mismo.
FUOC P08/M2104/00604
76
La importancia de este punto de control es doble: Por una parte, porque revisa, evala y valora el desarrollo cualitativo de las soluciones y su adecuacin a los requisitos estratgicos de la organizacin. Por otra parte, porque supone la finalizacin del proceso de creacin y adecuacin de la solucin y el inicio de la implantacin e integracin definitiva del sistema en la organizacin. En general, la fase de evaluacin del desarrollo es un buen momento para introducir a los usuarios en las particularidades del sistema, y se podr considerar la situacin como inicio de la formacin y adaptacin de los usuarios al nuevo entorno. Estas actuaciones se pueden enmarcar dentro de la gestin del cambio que tiene que llevar a cabo la organizacin, con el objetivo de vencer las eventuales reticencias y miedos de los usuarios23. La evaluacin final de la etapa de desarrollo puede acabar en tres grandes tipos de decisiones: Sistemaviableparaserimplantado. La evaluacin determina que el sistema cumple los requisitos de la organizacin y que se han desarrollado y se han integrado correctamente todas las modificaciones de la solucin original. Se puede iniciar la implantacin del sistema en la organizacin. Sistemaviableparaserimplantadoparcialmente. La evaluacin determina que el sistema cumple parcialmente los requisitos del proyecto en la fecha de control. Esta situacin se debe normalmente a retrasos en la produccin, 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 produccin. En cualquier caso, la viabilidad del proyecto no se ve afectada aunque habr que asumir un retraso en la implantacin. Sistemainviableparaserimplantado. Aunque no es habitual que el desarrollo de una solucin resulte inviable, es posible que excepcionalmente pueda haber factores que afecten a la resolucin y no se hayan podido solucionar durante la etapa. Este tipo de problemas se relacionan normalmente con factores externos al proyecto, como por ejemplo cambios bruscos en la estrategia o el agotamiento de la dotacin econmica. El aborto prematuro del proyecto en esta etapa tiene fuertes implicaciones econmicas, funcionales y morales en la organizacin, y dificultar posibles actuaciones futuras. El resultado de esta etapa es doble:
(23)
En ingls, FUD (fear, uncertainty and doubt).
FUOC P08/M2104/00604
77
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 estratgicas de la organizacin.
Por otra parte, se obtiene la valoracin de la viabilidad de la implantacin y eventuales ajustes en la planificacin temporal, como consecuencia de la evaluacin de eventuales pruebas piloto.
2.7. Implantacin y migracin En este apartado se profundizar en los detalles tcnicos de la implantacin y la migracin a sistemas basados en software libre.
La mayora de los proyectos de implantacin son tambin proyectos de migracin, ya que parten de un escenario en el cual hay un sistema informtico basado en software propietario que se encuentra ya en produccin. Los casos de implantacin desde cero se dan en organizaciones de nueva creacin que para la puesta en marcha de su primer sistema se orientan hacia una solucin basada en software libre, o bien en organizaciones que hasta ahora no disponan de ningn sistema informtico, lo cual pasa muy pocas veces.
Con respecto a los problemas tcnicos que el proyecto tiene que resolver, la implantacin desde cero es siempre mucho ms sencilla que la migracin, principalmente porque no se encontrar ningn problema de compatibilidad hacia atrs. No obstante, hay que tener en cuenta que los usuarios del nuevo sistema normalmente estarn familiarizados con sistemas operativos y aplicaciones de propiedad, por lo que la planificacin de la formacin es tan importante como en un proyecto de migracin. En este apartado siempre haremos referencia a proyectos de migracin, porque son los que presentan una mayor dificultad y tambin porque los proyectos de implementacin desde cero se pueden considerar como un subconjunto de los proyectos de migracin, con la particularidad que en este caso se tiene ms libertad para decidir el escenario final. Esta libertad presenta como contrapartida la necesidad de prestar ms atencin a aspectos no funcionales del sistema, como dimensionarlo correctamente, por ejemplo. As, se presentarn, en primer lugar, los diferentes tipos de proyectos de migracin y los aspectos ms importantes de la planificacin. En segundo lugar, se darn algunos consejos y orientaciones para ejecutar la migracin y evaluar
FUOC P08/M2104/00604
78
su resultado. Finalmente, se estudiarn en detalle todos los servicios implicados en el proyecto de migracin, as como las soluciones basadas en software libre ms populares para cada uno de ellos. 2.7.1. Tipos de migracin
Dentro de una organizacin se pueden llevar a cabo diferentes tipos de migracin a sistemas basados en software libre: segn los objetivos, es decir, segn cules sean los elementos del sistema que sern migrados, y segn el alcance, es decir, segn la cantidad de elementos que sern migrados. Segn el objetivo: Migracindeserviciosyservidores: afecta a los servidores de la organizacin y a las aplicaciones o servicios que se ejecutan, por ejemplo, el servicio de autentificacin o el servicio de impresin, entre otros. En este caso las aplicaciones de los clientes no cambian, por lo cual slo hay que prever formacin para los administradores de sistemas, y no para los usuarios finales. Son una de las migraciones ms fciles de llevar a cabo. En general, los servidores, funcionando con sistemas operativos GNU/Linux, de la familia BSD24 u otros igualmente libres, suelen ser ms fiables y ofrecen un rendimiento superior, lo cual aumentar la productividad de la organizacin, tanto de los administradores de sistemas como de los usuarios finales (menos tiempo de respuesta del servidor). Migracin de usuarios y clientes: afecta a las mquinas 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 acompaar a los usuarios finales, que en general son menos receptivos a la utilizacin de nuevas aplicaciones y sufrirn ms el cambio, con una posible prdida de productividad temporal. Migracindeaplicaciones: afecta tan slo a algunas de las aplicaciones que se ejecutan en los servidores o en las mquinas cliente, el sistema operativo del cual no tiene por qu ser GNU/Linux u otro sistema operativo libre. De hecho, lo ms habitual es que el sistema operativo contine siendo de propiedad. A veces es un paso previo a la migracin del sistema operativo. Son migraciones bastante sencillas de llevar a cabo, por ejemplo la migracin a OpenOffice.org o a MySQL Community Server. Segn el alcance: Migracincompleta: resulta de la combinacin de migrar tanto los servidores como las mquinas cliente. La planificacin de este tipo de migracin tiene que garantizar que los clientes no queden en ningn momento sin acceso a los servicios proporcionados por los servidores. Para ello, se
Ved tambin En el apartado "Diagrama de red y diagrama de estructura" se vern en detalle las particularidades de la migracin de cada uno de estos servicios.
(24)
OpenBSD, FreeBSD o NetBSD.
FUOC P08/M2104/00604
79
suele realizar en primer lugar la migracin total o parcial de los servidores y, a continuacin, la migracin de las mquinas cliente. Migracinparcial: resulta de la combinacin de migrar tan slo una parte de los servidores o una parte de los clientes, de manera que contina habiendo en el sistema mquinas basadas en software propietario. Un escenario habitual es aqul en el cual, en el mismo sistema, se encuentran clientes basados en software libre y clientes basados en software propietario, cuya configuracin depender de las necesidades o preferencias de los usuarios finales. Migracin basada en la virtualizacin: puede considerarse un tipo de migracin parcial, en la cual se lleva a cabo la migracin de servidores y mquinas clientes al mismo tiempo que se continan instalando y ejecutando aplicaciones basadas en software propietario que no se ha podido incluir en la migracin, ya sea por la ausencia de equivalentes en software libre o por otras razones. La virtualizacin permite iniciar un sistema operativo 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 tpico de migracin es aqul 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 integracin de la criptografa integrada, lo cual lo hace especialmente indicado para servidores u otro tipo de mquinas cuya integridad pueda verse comprometida.
2.7.2.
Estrategias de migracin
Como en todo proyecto, una planificacin correcta es una condicin imprescindible para asegurar el xito de la migracin a un sistema basado en software libre. Hay tantas planificaciones como proyectos, y todas sern ms o menos vlidas si se ajustan a los requisitos y las particularidades del escenario de migracin planteado. Sin embargo, segn la planificacin de la migracin, se pueden extrapolar cuatro grandes estrategias de migracin: Migracin en un nico paso: implica llevar a cabo todo el proceso de migracin en un corto espacio de tiempo, si puede ser en un solo da, o en das 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
y rechazo por parte de los usuarios. Esta estrategia es la ms econmica y se suele aplicar en sistemas de dimensiones reducidas, con pocos clientes y un nico servidor, por ejemplo en el caso de pequeas empresas. Migracinpiloto: implica llevar a cabo, en primer lugar, la migracin de una pequea parte del sistema, con la cual se practicar y evaluar el xito de la migracin, antes de proceder a la implantacin en el resto del sistema. El sistema piloto consiste en unos cuantos servidores y mquinas cliente, incluso podra tratarse de un solo servidor y una sola mquina cliente. Si bien una planificacin correcta es muy importante, esta estrategia permite una mayor flexibilidad para modificar el planteamiento de la migracin y corregir posibles problemas. En contrapartida, esta estrategia requiere muchos ms recursos y, por lo tanto, suele utilizarse en organizaciones con sistemas medianos o grandes. Migracinporgrupos: implica definir grupos de usuarios segn sus caractersticas funcionales y llevar a cabo la migracin gradualmente con cada 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. Adems, slo una parte del sistema se ve afectado por la migracin, lo cual permite suavizar la prdida de productividad. Como contrapartida, a menudo hay que mantener los sistemas anteriores en funcionamiento, mientras se va desplegando el sistema basado en software libre. La migracin por grupos normalmente es un buen momento para renovar el hardware, y viceversa. Migracinporusuarios: es similar a la migracin por grupos, con la particularidad que slo 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 nmero de usuarios prolongara durante demasiado tiempo la migracin. No obstante, puede ser aconsejable para llevar a cabo la migracin de sistemas y usuarios crticos que necesiten un seguimiento especial. Estas estrategias no son exclusivas y dentro de un mismo proyecto se pueden aplicar varias. Por ejemplo, en una organizacin en la cual ciertos departamentos de tamao ms reducido o de menor importancia lleven a cabo una migracin en un nico paso, y otros en los cuales se lleve a cabo una migracin piloto antes de la implantacin completa. De la misma manera, la migracin por grupos se puede ver como una combinacin de la migracin en un solo paso y la migracin piloto.
FUOC P08/M2104/00604
81
2.7.3.
Inventario de hardware y software
Para planificar la migracin hace falta identificar el hardware y el software existente en la situacin inicial, y de cules se espera disponer despus de la migracin. En consecuencia, se tiene que hacer un inventario detallado tanto del hardware como del software. El inventario de hardware tiene que incluir todas las mquinas disponibles para la migracin, incluidas las mquinas retiradas, ya que algunas se pueden reutilizar. El hardware se puede clasificar en las categoras siguientes: HardwaresoportadosinproblemasenGNU/Linux: se incluye hardware que desde el origen es soportado por el ncleo Linux o por controladores libres, as como hardware para el cual hay que utilizar controladores de propiedad, sea directamente o mediante adaptadores. La mayora de hardwares dispone de un buen soporte en GNU/Linux, por lo cual se clasifica en esta categora. Ms adelante se detallar cada una de estas situaciones. HardwaresoportadoconalgunaslimitacionesenGNU/Linux: se incluye hardware que funciona nicamente en versiones antiguas del ncleo Linux, que no son las utilizadas en las distribuciones GNU/Linux ms recientes, hardware que funciona con controladores muy antiguos para los cuales no existe mantenimiento y hardware cuyos controladores libres presentan limitaciones funcionales con respecto a los controladores de propiedad .
Distribucin GNU/Linux La produccin de una distribucin GNU/Linux implica la verificacin que todos los paquetes incluidos en la distribucin son compatibles entre ellos y, especialmente, con la versin del ncleo. Por ello hay siempre un desfase de diversos meses entre la fecha de aparicin de la distribucin y la de su ncleo, ms antiguo.
25 (25)
Como por ejemplo, adaptadores grficos con aceleracin 3D cuyos controladores libres slo disponen del modo 2D.
HardwarenosoportadoenGNU/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, cundo eso pasa, se debe bien al hecho de que el hardware es muy nuevo y todava no se han desarrollado los controladores apropiados, bien al hecho de que el hardware es muy antiguo y es incompatible con versiones ms nuevas del ncleo Linux, bien al hecho de que el hardware es dependiente de un sistema operativo en concreto y, por lo tanto, inutilizable en GNU/Linux26.
(26)
No obstante, en este caso, una solucin basada en la virtualizacin podra ser posible.
A su vez, el hardware soportado por GNU/Linux se puede clasificar segn el tipo de soporte de la siguiente manera:
FUOC P08/M2104/00604
82
Hardware soportado desde el origen por GNU/Linux: la mayora de equipos y sus dispositivos disponen de un soporte adecuado en las distribuciones GNU/Linux recientes, y por eso no hay que recurrir a controladores externos. Es fcil encontrar en Internet listas del hardware soportado por GNU/Linux.
Pgina web Podis informaros sobre hardware soportado por GNU/Linux en: http:// hardware4linux.info/.
Hardwaresoportadoporcontroladoreslibres: una parte importante de los dispositivos, si bien no estn soportados desde el origen por GNU/Linux, funcionan correctamente con controladores mantenidos por la comunidad de software libre. A menudo, los gestores de paquetes incluidos con las distribuciones GNU/Linux proponen la instalacin de estos controladores cuando detectan el hardware.
Pgina web NDISwrapper es un proyecto de software libre que permite utilizar tarjetas de red inalmbricas bajo GNU/Linux mediante controladores Windows.
Hardwaresoportadoporcontroladorespropietarios: para este tipo de dispositivos no hay controladores mantenidos por la comunidad de software libre, y entonces hay que utilizar controladores propietarios a menudo suministrados por el mismo fabricante. Suele tratarse de hardware con funcionalidades muy especficas, por ejemplo las aceleradoras grficas. Sin embargo, poco a poco el soporte para este tipo de dispositivos va aumentando y a menudo los mismos fabricantes liberan sus controladores.
Hardwaresoportadomedianteadaptadores: son aqullos para los cuales no hay soporte en GNU/Linux, pero s para otros sistemas operativos de propiedad. Afortunadamente, hay herramientas denominadas adaptadores que permiten utilizar controladores de estos sistemas operativos de propiedad bajo GNU/Linux.
La clasificacin correcta del hardware permitir hacerse una idea precisa de los recursos disponibles, as como de la necesidad eventual de comprar nuevos equipos. Por otra parte, como se ha comentado anteriormente, se puede destacar que los requisitos de hardware de los sistemas GNU/Linux son considerablemente menores que los de los sistemas operativos de propiedad, por lo cual mquinas obsoletas pueden reutilizarse con el fin de ofrecer servicios de impresin o de correo electrnico, 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 migracin, basadas en software propietario, y las mejores aplicaciones basadas en software libre que puedan sustituirlas.
FUOC P08/M2104/00604
83
En Internet hay muchas listas con las equivalencias entre aplicaciones de propiedad y libres. Sin embargo, a veces habr que llevar a cabo un estudio detallado de las funcionalidades de cada aplicacin para escoger al mejor candidato entre las opciones basadas en software libre. Cuando se trata de aplicaciones de uso ms comn, como las ofimticas, el nmero de opciones es elevado y a menudo hay una aplicacin o un paquete de aplicaciones que destaca por encima de las otras. Para aplicaciones de usos ms especficos 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 organizacin podra evaluar la posibilidad de desarrollar la aplicacin en la medida de sus necesidades y liberarla bajo una licencia libre, siempre que disponga de bastantes recursos. Los beneficios son evidentes: la contribucin potencial de desarrolladores y usuarios externos y el aumento de la visibilidad para la organizacin. 2.7.4. Diagrama de red y diagrama de estructura
Pgina web El proyecto SourcePYME ofrece una lista de aplicaciones y servicios bastante extensa y actualizada (http:/ /www.sourcepyme.org/ ?q=node/13). Hay igualmente un gran nmero de recursos en ingls.
Ved tambin En el apartado "Evaluacin de la migracin" se presentarn las alternativas existentes para la migracin de los servicios esenciales de una organizacin.
En este apartado se presentarn dos elementos esenciales en una migracin de sistemas: el diagrama de red, que muestra la conectividad entre los diferentes elementos del sistema, y el diagrama de estructura, que indica su ubicacin fsica. De esta manera, una vez se conoce el hardware y el software que se ver afectado por la migracin, 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. Equiposclienteodeusuario. Se indicar el nombre del equipo, as como los dispositivos de red que estn expuestos al resto del sistemas. Impresoras. Se indicar el nombre de la impresora y de qu servidor de impresin o de qu equipo cliente dependen. Otrosequiposdered. Se indicarn 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 inalmbrico o access points. Conectividadentreloselementos. Se indicarn las conexiones de red por cable e inalmbricas entre los diferentes elementos del sistema. Se indicar igualmente la salida a redes externas desde la red local de la organizacin
Pgina web Una excelente aplicacin 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
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 unvoca. En primer lugar, se har un diagrama de red que recoja el estado del sistema antes de la migracin. A partir de este diagrama se estudiarn cules son las posibilidades de optimizacin de la red actual, como resolver cuellos de botella en los servidores o conectar ciertas impresoras locales en un servidor central de impresin. De la misma manera, se decidir qu equipos nuevos y qu elementos de red se introducirn en el sistema como nuevos servidores, equipos antiguos que puedan funcionar con GNU/Linux o el despliegue de una red inalmbrica. Con estos elementos se construir el diagrama de red del sistema posterior a la migracin. Este diagrama ser esencial para definir la planificacin y la estrategia de la migracin, y mientras dure la implantacin servir siempre de gua. Por eso convendr mantener el diagrama de red siempre al da, de manera que refleje fielmente el estado del sistema. Como se ha comentado al principio del apartado, el diagrama de estructura refleja la ubicacin fsica de los equipos dentro de la organizacin 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 disear un diagrama de estructura que represente el estado del sistema antes de la migracin a partir del cual se podr decidir la ubicacin de los equipos despus de hacer la migracin. Una de las consecuencias ms frecuentes de la migracin es la puesta en marcha de servidores dedicados a un reducido nmero de servicios, a veces incluso en exclusiva. Por ello los servidores suelen agruparse en la misma ubicacin fsica (tpicamente una sala de servidores), que presentar requisitos particulares de climatizacin, suministro de energa y accesibilidad, entre otros. Otro ejemplo es la conexin de impresoras (hasta ese momento locales) en un servidor de impresin, que se pueden ubicar en la misma sala. Si bien en organizaciones reducidas, con un entorno de una decena de equipos, el diagrama de estructura no es especialmente importante, en escenarios de migracin extensos resulta imprescindible para ubicar cada uno de los equipos y elementos de red.
FUOC P08/M2104/00604
85
2.7.5.
Ejecucin de la migracin
En la ejecucin de toda migracin, e independientemente de la estrategia de migracin que se haya adoptado, hay una serie de tareas tcnicas que casi siempre se repiten: instalacin de equipos, migracin de datos, realizacin de copias de seguridad, emulacin de aplicaciones. Junto con estas tareas tcnicas, destaca la importancia de disponer de un plan de gestin de los riesgos que pueden presentarse en la migracin.
En este apartado veremos brevemente cada una de estas tareas y daremos algunas orientaciones para llevarlas a cabo: Instalacin de equipos. Hay herramientas de instalacin automtica de equipos con el fin de poder instalar y configurar fcilmente muchos en un tiempo reducido. Una de estas herramientas es SystemImager, que permite automatizar la instalacin de imgenes o clones del sistema GNU/Linux instalado en un primer equipo. SystemImager permite tambin distribuir nuevas aplicaciones o datos en los equipos del sistema y realizar cambios en la configuracin o instalar actualizaciones del sistema en redes con equipos GNU/Linux. Sin embargo, en caso de que el hardware de los equipos no sea idntico, puede ser que haya que configurarlos manualmente. Migracindedatosdeusuario. Los nombres y direcciones de los usuarios suelen almacenarse en servicios de directorio, normalmente accesibles a travs del protocolo estndar LDAP, que facilita la migracin 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 esquemas de datos diferentes para estructurar la informacin. En consecuencia, los datos son pocas veces interoperables entre ellos y entonces hay que utilizar programas externos que sincronicen los datos entre aplicaciones. Realizacin 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 despus de una prdida de informacin. La implantacin de sistemas GNU/Linux comporta a menudo el formateo y particin de los equipos implicados en la migracin, por lo cual habr que realizar copias de seguridad de los datos existentes, con el fin de restaurarlas despus en el nuevo sistema.
SystemImager SystemImager permite guardar la imagen de un sistema GNU/ Linux en produccin antes de realizar cambios en el sistema, lo que garantiza poder volver a la situacin original. Pgina web Podis encontrar ms informacin sobre SystemImager en http:// wiki.systemimager.org/.
Ved tambin Podis consultar el apartado "Inventario de hardware y software" para obtener ms detalles sobre la migracin de servicios de directorio.
FUOC P08/M2104/00604
86
Si la organizacin dispone de un mecanismo de copia de seguridad actualizado, una buena opcin es utilizarlo para recuperar toda la informacin que tenga que ser copiada en los nuevos equipos. Si la organizacin no dispone de ningn mecanismo de copia de seguridad, se puede poner en marcha un servicio de almacenamiento exclusivamente para almacenar los datos que tienen que migrar. Otra opcin es desplegar en primer lugar el servicio de almacenamiento previsto en el plan de proyecto y proporcionar 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 participacin de los usuarios es fundamental. Por otra parte, una vez concluida la migracin har falta poner en marcha un mecanismo de copias de seguridad incremental . Como regla general, el sistema original y la copia tienen que ser cuanto ms independientes mejor, de manera que un error en uno no afecte al otro. Emulacindeaplicacionesyvirtualizacin. La realizacin del inventario de software servir para saber qu aplicaciones no se pueden ejecutar de manera nativa en GNU/Linux y tampoco pueden ser sustituidas por una aplicacin libre equivalente. En caso de que estas aplicaciones sean imprescindibles, hay dos posibles soluciones con el fin de poder continuar utilizndolas: la emulacin y la virtualizacin.
Wine, la solucin libre ms popular Wine es la solucin libre ms 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 ms 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 particin Windows, aunque en algunos casos puede convenir disponer de algunas bibliotecas nativas de Windows. Las aplicaciones ejecutadas con Wine pueden acceder al sistema de archivos, la red y los servicios de impresin de manera completamente transparente. En el sitio web de Wine pueden consultarse qu aplicaciones estn soportadas y con qu nivel de funcionalidad. Para aplicaciones que no se ejecuten correctamente con Wine hay la posibilidad de ejecutarlas en un sistema operativo virtualizado. Como se ha introducido anteriormente, la virtualizacin permite ejecutar un sistema operativo encima de otro. En este caso se tratara de ejecutar la aplicacin en un sistema Windows virtual sobre un sistema GNU/ Linux. Las soluciones libres ms populares de virtualizacin son QEMU, Xen i KVM. En cualquier caso, la virtualizacin siempre se tiene que considerar en ltimo lugar, ya que implica continuar utilizando y pagando licencias de propiedad y supone un gran consumo de recursos del sistema.
27 (27)
Hay mltiples soluciones disponibles, entre las cuales destaca RSync (http://samba.anu.edu.au/ rsync) y Amanda (http:// amanda.org).
Gestinderiesgos. La migracin 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 gestin y mantenerlo durante toda la ejecucin del proyecto.
Ved tambin Podis consultar el apartado "Gestin de riesgos" para obtener ms detalles sobre la realizacin de planes de gestin de riesgos.
FUOC P08/M2104/00604
87
Los riesgos y su importancia relativa dependern del escenario de migracin y de las particularidades de la organizacin. Por ejemplo, para ciertas organizaciones 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 migracin sea reversible hasta que no se haya verificado completamente el nuevo sistema, es decir, que se pueda volver a la situacin de partida en el caso improbable de que la migracin falle o acabe siendo inviable. 2.7.6. Evaluacin de la migracin
En todo proyecto de migracin es esencial llevar a cabo una evaluacin tanto del sistema final como del proceso de migracin. Esta evaluacin puede hacerse una vez concluida la migracin, pero tambin 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, segn hagan referencia al sistema operativo, a los servidores, a las aplicaciones o a los usuarios: Indicadoresdelsistema. Se ha aumentado la fiabilidad, el rendimiento y la seguridad del sistema despus de la migracin? Cmo ha variado el coste real (no estimado) de mantenimiento del sistema? Se han desplegado nuevos servicios en el sistema? Cul es la valoracin de los administradores del nuevo sistema? Ha disminuido el nmero de incidencias de los diferentes servicios del sistema despus de la migracin? Indicadoresdelsistemaoperativo. Cuntos equipos han sido migrados al nuevo sistema? Funcionan correctamente todos los equipos? Todo el hardware est soportado en el nuevo sistema? Cuntas veces ha habido que recurrir a soluciones basadas en la virtualizacin? Indicadoresdelasaplicaciones. Para cuntas de las aplicaciones existentes se ha encontrado y ha sido implantada una aplicacin equivalente en software libre? Qu funcionalidades se han ganado o se han perdido con respecto a las aplicaciones originales? Cuntas aplicaciones funcionan bajo emulacin o virtualizacin? Cuntas aplicaciones ha sido necesario modificar? Cuntas aplicaciones se han tenido que desarrollar desde cero? Indicadoresdelosusuarios. Cuntos usuarios han sido migrados al nuevo sistema? Cul es su valoracin de los aspectos funcionales y no fun-
FUOC P08/M2104/00604
88
cionales del nuevo sistema y de las nuevas aplicaciones? Cul ha sido la variacin de su productividad a corto y largo plazo? Ha disminuido el nmero de incidencias de usuario al instalar el nuevo sistema operativo?
2.7.7.
Migracin de los servicios de un sistema
En la mayora de las organizaciones hay una serie de servicios esenciales, a los cuales se tiene que prestar especial atencin a la hora de planificar y ejecutar la migracin: Sistema de archivos Servicio de impresin Servicio de directorio y autentificacin Servicio de red Gestin y administracin del sistema Servidores web Bases de datos Entornos de escritorio y aplicaciones ofimticas Aplicaciones corporativas
En este apartado, se presentarn las caractersticas principales de estos servicios y se mostrarn las soluciones basadas en software libre ms populares. En general, siempre hay ms de una alternativa, por lo que la eleccin final depender de las caractersticas y requisitos de cada escenario.
Aclaracin Si bien la mayora 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 escenarios, la tecnologa evoluciona continuamente, por lo cual es aconsejable visitar los sitios web de cada uno de los proyectos para obtener la informacin tcnica ms reciente e investigar otras soluciones que pudieran mejorar las existentes.
Igualmente, la importancia de cada uno de estos servicios ser diferente en funcin de las caractersticas de la organizacin. Es posible que algunos de estos servicios no se encuentren presentes en la situacin inicial y, por lo tanto, no se incluyan en la migracin. Sin embargo, la migracin representa una excelente oportunidad para analizar y revisar el estado actual del sistema y disear una arquitectura que responda tanto a las necesidades actuales de la organizacin como a aqullas necesarias a largo plazo. Por ello se tiene que considerar la inclusin de nuevos servicios no presentes en el sistema original.
FUOC P08/M2104/00604
89
Sistema de archivos En la migracin del sistema de archivos pueden darse dos situaciones, segn si migran todos los clientes o tan slo una parte: Migracindelservidordelsistemadealmacenamientoperonodelos clientes En este caso, la opcin ms popular es el uso de Samba. Samba es una implementacin libre del protocolo utilizada en sistemas de archivos compartidos de Microsoft Windows para sistemas Unix que permite que ordenadores con GNU/Linux acten como servidores o clientes en redes Windows. Migracindelservidordelsistemadealmacenamientoydelosclientes 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, OpenAFS28 es un sistema de archivos distribuido, utilizado generalmente en centros de servidores (clusters) y en escenarios de computacin distribuida. La eleccin entre el uno y el otro (o la eleccin de otro sistema) depender de los requisitos de la migracin. Es posible utilizar NFS o OpenAFS en redes que incluyan clientes Windows y GNU/Linux. Para la migracin de los servidores que funcionan con GNU/Linux, hay mltiples sistemas de archivos, pero los ms conocidos son Ext3 y XFS. Sus funcionalidades incluyen journaling, asignacin de cuotas y privilegios de acceso basados en ACL (Access Control List) por archivo y directorio. Un aspecto a tener en cuenta en la migracin del sistema de archivos es el mapeo de las ACL Windows a las ACL Posix, en el cual se puede perder cierta granularidad. En la prctica eso no suele pasar, ya que habitualmente las organizaciones hacen un uso completo de la granularidad permitida por las ACL Windows. Servicio de impresin La impresin es una de las fuentes de problemas ms recurrentes en todas las organizaciones, en general a causa de la instalacin de impresoras sin ninguna planificacin, cosa que comporta numerosas incidencias tcnicas y, a menudo, el despilfarro de recursos (papel, tinta, electricidad). De hecho, la migracin a un sistema basado en software libre se presenta como una buena oportunidad para optimizar el servicio de impresin.
(28)
OpenAFS es una implementacin libre de un sistema de archivos originariamente desarrollado por la Universidad Carnegie Mellon, que influy tambin en el diseo de NFS.
FUOC P08/M2104/00604
90
Entre las soluciones basadas en software libre, CUPS es el servidor de impresin utilizado por la mayora de distribuciones GNU/Linux y es de hecho la mejor opcin en casi todos los escenarios de migracin. Una de sus principales ventajas es que permite disponer de un servicio de impresin tanto para clientes GNU/Linux como para clientes Windows, gracias a la implementacin del protocolo de impresin por Internet (Internet Printing Protocol, IPP). El protocolo IPP es un estndar de impresin tanto en redes LAN como WAN y soporta la comunicacin 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 migracin se tienen que comprobar el soporte y los controladores existentes para cada impresora. Servicio de directorio y autentificacin Un servicio de directorio tiene como finalidad que una determinada informacin est disponible para todos los usuarios de una red. Esta informacin normalmente est compuesta por objetos que se organizan de una manera jerrquica, con su origen en un objeto raz. El protocolo que se utiliza ms a menudo para acceder es el LDAP.
LDAP (Lightweight Directory Access Protocol) Inicialmente, el LDAP haca referencia slo al protocolo de acceso. Sin embargo, hoy en da se entiende por LDAP la combinacin de la base de datos que contiene la informacin y el protocolo para acceder a ella.
Por ejemplo, un uso bastante frecuente de un servicio de directorio es almacenar 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 informacin, que dada su naturaleza es aconsejable que sea ntegra. As, un servicio de directorio tiene que ofrecer las siguientes funcionalidades: Tiene que modificar la informacin disponible y organizarla segn una estructura jerrquica. Tiene que usar un esquema de datos estndar, que asegure la compatibilidad y la interoperabilidad con el mayor nmero de aplicaciones. Tiene que autentificar usuarios y garantizar la interoperabilidad con otros servicios de autentificacin. Tiene que administrar los derechos de acceso a la informacin contenida en el servicio de directorio. Tiene que garantizar la seguridad en la transmisin de la informacin entre los clientes y el servicio de directorio.
FUOC P08/M2104/00604
91
Con el fin de llevar a cabo la autentificacin junto con un servicio de directorio, la solucin basada en software libre ms frecuente es la combinacin de OpenLDAP con Samba, en la cual ste ltimo sirve como base de datos de las cuentas de usuario, mientras que OpenLDAP acta como servicio de directorio. Un gran nmero de aplicaciones son compatibles con LDAP, como el paquete ofimtico OpenOffice.org. El sistema GNU/Linux ofrece diversas herramientas LDAP29 que permiten modificar la informacin almacenada en el servicio de directorio, y hay tambin diferentes interfaces grficas basadas en Web para la administracin de usuarios y grupos. Un servicio de directorio y autentificacin basado en OpenLDAP y Samba permite adems el uso de clientes Windows y Linux simultneamente. De hecho, OpenLDAP acta al mismo tiempo como parte del servicio de autentificacin y como herramienta de integracin en escenarios mixtos con clientes GNU/ Linux y Windows. En caso de que la migracin a GNU/Linux sea completa, es posible tambin llevar a cabo la autentificacin mediante Kerberos. Kerberos es un protocolo de autentificacin que permite que dos ordenadores demuestren mutuamente su identidad de una manera segura. Servicios de red Toda la infraestructura de redes TCP/IP (DNS, DHCP, NTP, conexin de encaminadores, filtraje, VPN) puede implementarse fcilmente mediante soluciones basadas en software libre, lo cual se debe principalmente al hecho de que todos los protocolos de Internet son estndares abiertos, tanto en su definicin como en sus implementaciones. Un aspecto a considerar en la migracin de los servicios de red es la utilizacin de estndares abiertos, incluso en el caso en que no se tengan que utilizar (por ejemplo, en el caso de una pequea red local), y as evitar el uso de modificaciones especficas de los fabricantes de hardware, que a la larga podran provocar 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(sistemadenombresdedominioodomainnamesystem) La implementacin de referencia en software libre es BIND (Berkeley Internet Name Domain), mantenida en la actualidad por la Internet Systems Consortium (ISC). BIND es el servidor de DNS ms utilizado en Internet. La ltima versin es BIND 9, que incorpora DNSSEC (DNS Security Extensions), TSIG (Transaction Signature), notificacin DNS, nsupdate y Ipv6 entre otras funcionalidades. Est disponible en todos los sistemas GNU/Linux.
Internet Systems Consortium Internet Systems Consortium es una organizacin sin nimo de lucro y el sucesor del Internet Software Consortium, tambin denominado ISC. Nota Podis consultar ms informacin de los estndares abiertos en el anexo II de este mdulo didctico.
(29)
Por ejemplo, ldapsearch, ldapad y ldapmodify.
FUOC P08/M2104/00604
92
DHCP(protocolodinmicodeconfiguracindehuspedodynamichost configurationprotocol) La implementacin de referencia en software libre es dhcpd, tambin mantenida en la actualidad por el ISC. dhcpd permite administrar clientes individuales y configuraciones colectivas para clases y subredes. Adems, dhcpd ofrece funcionalidades de balance de carga y alta disponibilidad. Est disponible en todos los sistemas GNU/Linux. NTP(protocolodetiempoderedonetworktimeprotocol) NTP es un protocolo de Internet que permite sincronizar los relojes de los sistemas informticos a travs de el encaminamiento de paquetes, para evitar los problemas derivados de latencia variable en las redes. El NTP Project proporciona soporte para NTP y ofrece una implementacin de referencia, disponible en todos los sistemas GNU/Linux. WINS(WindowsInternetnameservice) WINS permite resolver los nombres de los diferentes servicios y sistemas Windows. Esta funcin se puede sustituir por nmbd, incluido en el paquete Samba. Gestin y administracin del sistema La mayora de aplicaciones de control y de gestin de sistemas no son nativas en el sistema operativo y los fabricantes a menudo proporcionan versiones de estas aplicaciones para diferentes sistemas operativos. Esta situacin presenta el inconveniente de que si bien hay un buen nmero de aplicaciones de gestin de sistemas para GNU/Linux, no estn basadas en software libre. En cualquier caso, la gestin y el control de sistemas basados en software libre es muy diferente de la de sistemas basados en software propietario, como Windows. Los administradores de sistemas basados en software libre normalmente no utilizan una nica herramienta de gestin, sino un conjunto, cada una de las cuales especializada en una parte del sistema. De esta manera, los administradores tienen mucha ms 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 opcin para la automatizacin de tareas de administracin en GNU/Linux es la utilizacin de cron y at. El primero (cron) es un administrador de procesos en segundo plano que ejecuta programas a intervalos regulares. De una manera similar, la orden at permite la ejecucin de programas en un momento determinado.
FUOC P08/M2104/00604
93
Por otra parte, todo sistema GNU/Linux ofrece la funcionalidad bsica de administracin a travs de una terminal remota ssh en otro cliente o servidor, exactamente de la misma manera que si se tratara de su mquina local, incluso a travs de la interfaz grfica del escritorio. El uso combinado de ssh con cron y at permite al administrador realizar una buena parte de las tareas de mantenimiento. Adems, otras utilidades del sistema como strace, lsof o netstat ofrecen diferentes funcionalidades para detectar y analizar errores y pueden resultar tiles en la gestin de servidores. Gestindered Entre las soluciones disponibles para la gestin 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 controla los servidores y servicios especificados y enva la informacin al servidor de Nagios, que a su vez notifica al administrador del sistema en caso de que se detecte algn problema. Mediante una serie de plugins, Nagios permite monitorizar de manera activa y pasiva servicios de red tpicos como servidores de Web y de correo, pero tambin otros, como sistemas gestores de bases de datos. Por su parte, openNMS es una aplicacin de gestin de redes que cumple el modelo FCAPS y permite determinar la disponibilidad de los diferentes servicios, almacenar la informacin y generar informes y notificar acontecimientos. No obstante, hay que tener en cuenta que la gestin de sistemas y redes de ms complejidad puede requerir utilizar herramientas que no estn disponibles como software libre. Gestindesoftware La gestin de software implica la instalacin y restauracin de clientes, las distribuciones de aplicaciones estndar y especficas y la gestin de actualizaciones 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 distribucin Debian, que permite la instalacin inicial de los clientes, incluyendo la definicin de particiones y la deteccin de hardware, la distribucin y actualizacin de software y la restauracin de clientes.
FUOC P08/M2104/00604
94
Servidor web Apache es la principal alternativa para migrar e implantar el servidor web de una organizacin. Apache est presente en ms del 60% de los servidores web y se distribuye libremente bajo la licencia Apache. Sus funcionalidades y rendimiento son excelentes y estn sobradamente contrastados en todo tipo de escenarios de produccin. La arquitectura de Apache es modular y consiste en un ncleo que contiene las funcionalidad bsicas del servicio y un gran nmero de mdulos fcilmente instalables para aplicaciones especficas, como para soportar determinados lenguajes de programacin como PHP, Java, Perl, etc. La migracin de proyectos web30 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 estticos (desarrollados en HTML) como dinmicos (desarrollados en lenguajes como PHP o Perl). Normalmente, las modificaciones que se tienen que aplicar en estos proyectos para asegurar su compatibilidad bajo Apache sern mnimas o nulas. Un caso especial son los proyectos desarrollados en tecnologas de propiedad como ASP, que requieren un esfuerzo importante para que funcionen bajo Apache. Siempre que sea posible, es preferible implementar de nuevo el proyecto web en tecnologas alternativas como PHP, de manera que se asegure la independencia tecnolgica 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 organizacin. De hecho, la utilizacin de PHP como lenguaje de programacin para la Web es cada vez ms frecuente y en los ltimos aos se han generalizado las plataformas 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 implantacin de sistemas gestores de bases de datos, pero las ms conocidas son MySQL, PostgreSQL, Firebird y MaxDB. La eleccin de una solucin u otra depender del anlisis de los requisitos de la migracin. En cualquier caso, las bases de datos libres son productos maduros que han sido probados en entornos de produccin y, de hecho, se pueden considerar como una de las puntas de lanza del software libre y del sistema GNU/Linux
(30)
El proyecto Apache Apache es uno de los proyectos desarrollados por la comunidad de software libre de ms xito, y a causa de ciertas particularidades de su licencia puede ser utilizado en productos de software propietario.
Por proyecto web se entiende tanto una pgina web (por ejemplo, la pgina web de la organizacin) como las aplicaciones basadas en web y accesibles a travs de un navegador.
FUOC P08/M2104/00604
95
en los entornos empresariales. Hay que destacar tambin que estas soluciones cuentan con versiones para sistemas operativos de propiedad, por lo cual podran utilizarse en una migracin nicamente de aplicaciones. Algunas bases de datos de propiedad como Oracle31 disponen tambin de una versin 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 sera posible realizar la migracin del sistema operativo en GNU/Linux. La mayora de bases de datos ofrecen mecanismos ms o menos estndar para su administracin y consulta, lo cual en principio favorece la interoperabilidad y la utilizacin de otras soluciones, as como una migracin fcil 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 modificacin adicional. De esta manera, la migracin de bases de datos implica llevar a cabo dos operaciones: Migracindedatosalanuevabasededatos. Esta operacin requerir ms o menos esfuerzo segn el estado inicial de los datos. En caso de que los datos sean accesibles mediante consultas SQL, una operacin de exportacin o trasvase de datos y la posterior importacin a la nueva base de datos tendra que ser suficiente. En caso de que los datos se encuentren almacenados en algn formato de propiedad o incluso en ficheros de texto, har falta implementar un analizador sintctico (parser) e importarlos despus a la nueva base de datos. Verificacindelaccesoadatosdesdelasaplicaciones. En caso de que las aplicaciones utilicen un mecanismo estndar para leer los datos, por ejemplo consultas SQL, el acceso se tendra que realizar de la misma manera, excepto si se utilizan comandos que no satisfacen el estndar. En caso de que las aplicaciones utilicen controladores estndar 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 implementar 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 migracin de bases de datos, se debe evitar como sea la utilizacin de procedimientos de consulta predefinidos y extensiones especficas de los fabricantes en el acceso a los datos desde las aplicaciones. Por contra, es recomendable utilizar controladores estndar como ODBC o JDBC, fcilmente intercambiables, e implementar las consultas SQL de la manera ms modular y aislada con respecto al resto del programa.
(31)
Oracle suele utilizarse en entornos bastante complejos que presentan una serie de requisitos que a veces las soluciones libres no ofrecen.
FUOC P08/M2104/00604
96
Entornos de escritorio y aplicaciones ofimticas En los sistemas GNU/Linux hay dos grandes alternativas de entornos de escritorio: GNOME y KDE. Tanto GNOME como KDE proporcionan un entorno de escritorio intuitivo que incluye un gestor de ventanas fcil 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 eleccin entre uno u otro depende en gran manera de los gustos personales. En general, KDE ofrece una interfaz ms similar a la de Windows y ms posibilidades de personalizacin, que sin embargo pueden suponer una dificultad adicional para los nuevos usuarios. Por otra parte, si bien hay un gran nmero de aplicaciones ofimticas para los sistemas GNU/Linux que se integran bien con los sistemas de escritorio Gnome y KDE, hay dos soluciones que destacan de entre las otras: OpenOffice.org y StarOffice. OpenOffice.org es un paquete ofimtico de software libre y cdigo abierto de distribucin libre. Est disponible para mltiples plataformas tanto libres como de propiedad, por lo cual se encuentra a menudo como ejemplo de migracin de aplicacin. En la mayora de los casos es compatible con Microsoft Office y soporta el estndar 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 ofimtico de propiedad y de pago de Sun Microsystems y contiene algunas funcionalidades adicionales32 con respecto a OpenOffice.org, a la cual Sun Microsystems contina dando su apoyo. Tanto OpenOffice.org como StarOffice incluyen diferentes aplicaciones, cada una de las cuales con unas funciones concretas, pero que se integran perfectamente las unas con las otras: Procesador de textos (Writer) Hoja de clculo (Calc) Presentacin (Impress) Editor de frmulas matemticas (Math) Dibujo (Draw) Base de datos (Database)
(33) (32)
Fuentes TrueType similares a las utilizadas por Microsoft, plantillas y galeras de imgenes adicionales y parches y actualizaciones adicionales, entre otros.
OpenOffice.org33 utiliza un formato comprimido de archivos basado en XML para todas sus aplicaciones, que difiere de los formatos binarios utilizados por otras aplicaciones ofimticas de propiedad. Este formado permite separar f-
La mayora de caractersticas de OpenOffice.org que se citarn en el apartado son extensibles a StarOffice.
FUOC P08/M2104/00604
97
cilmente el contenido del archivo de sus datos, sus estilos, el control de versiones y las imgenes incluidas en el documento. OpenOffice.org permite igualmente trabajar con otros formatos basados tambin en XML. MigracindearchivosenformatoMicrosoftOffice OpenOffice.org incluye tambin mecanismos para convertir e importar archivos en formatos de propiedad, como los utilizados por el paquete ofimtico 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 mayora de los casos aceptable, en ocasiones pueden aparecer diferencias en el formato de los documentos, sobre todo en aqullos que incluyen elementos complejos, como macros u otras caractersticas especiales. En este caso puede ser que sea necesario reeditar algunos de estos documentos si se quiere que su formato sea idntico al del original. Por ello, antes de convertir y migrar los documentos, hace falta estudiar las particularidades y clasificarlos segn su uso y su complejidad tcnica: Documentos editables: tienen que ser convertidos a un nuevo formato interoperable, como ODT, de manera que puedan ser editados en el futuro. Documentos de slo lectura: podran ser convertidos al formato PDF, lo cual simplifica considerablemente el proceso de migracin. Documentos sencillos: no contienen macros, grficos de propiedad, formatos o estilos o elementos complejos, como notas al pie, tablas e ndices. Pueden migrarse fcilmente mediante un tratamiento por lotes (batch). Documentos complejos: pueden contener macros, grficos de propiedad y grficos vectoriales, objetos OLE, objetos activos, referencias cruzadas, etc. Se pueden migrar, pero lo ms probable es que exijan un tratamiento individual. OpenOffice.org ofrece la posibilidad de convertir un gran nmero de documentos mediante un tratamiento por lotes. Todos los documentos se tendrn que encontrar en un directorio de origen y se especificar un directorio de destino, en el cual se guardarn todos los documentos convertidos. De todos modos, es recomendable verificar la exactitud de la conversin con una muestra representativa de todos los documentos. Por otra parte, cuando se trate de documentos complejos, hay dos posibilidades:
FUOC P08/M2104/00604
98
Realizar la conversin documento a documento, de manera que se puedan 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 conversin y, a continuacin, realizar un tratamiento de todos ellos por lotes.
Aplicaciones corporativas
Por aplicaciones corporativas se entienden aqullas que han sido desarrolladas a medida, para responder a las necesidades concretas de la empresa u organizacin sobre la cual se lleva a cabo la migracin.
A los efectos de la migracin, podemos distinguir entre los tipos de aplicaciones corporativas siguientes: Aplicaciones que pueden ejecutarse sin problemas en un sistema operativo 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 ejecutar en un sistema operativo libre. Por ejemplo, para acceder correctamente 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 emulacin o virtualizacin. Aplicaciones que no pueden ejecutarse en un sistema operativo libre. Por ejemplo, las aplicaciones implementadas en lenguajes exclusivamente para el sistema operativo de propiedad. La mayora de aplicaciones corporativas son propietarios y en consecuencia la empresa no dispone del cdigo fuente. En caso de que no sea posible ejecutar de ninguna manera la aplicacin mediante emulacin o virtualizacin, la opcin ms recomendable es implementar de nuevo la aplicacin como software libre, basndose, a ser posible, en algn proyecto de software libre ya existente. 2.8. Formacin, comunicacin y soporte al usuario Hasta ahora se han presentado mayoritariamente los aspectos tcnicos de la implantacin de sistemas basados en software libre. La importancia de la tecnologa no debe esconder que uno de los factores de xito de cualquier proyecto de implantacin, y en especial en las situaciones de migracin, es la aceptacin del nuevo sistema por parte de sus usuarios.
FUOC P08/M2104/00604
99
En este apartado se presentar en primer lugar los elementos principales del plan de formacin en software libre en una organizacin y algunas buenas prcticas con el fin de facilitar la introduccin y la aceptacin de los usuarios. Para concluir, se repasarn los principales canales de comunicacin y los elementos fundamentales de un sistema de soporte al usuario. 2.8.1. Formacin
La formacin adecuada de los usuarios tiene un papel importantsimo 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 formacin se tiene que identificar en primer lugar qu grupos de usuarios utilizarn unos tipos de aplicaciones concretas u otros. De esta manera se podrn estudiar las diferencias entre las aplicaciones de propiedad y las libres y, en consecuencia, evaluar la dificultad que supondr la adopcin de las nuevas aplicaciones para los usuarios. Con estos elementos ser posible planificar una formacin 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 electrnico o las aplicaciones ofimticas. Es evidente que en estos casos la necesidad de formacin ser menor. Materiales Hay un gran nmero de materiales en Internet que pueden utilizarse para la formacin de los usuarios o para preparar materiales propios. Hay que tener en cuenta que a menudo los manuales y la documentacin estn disponibles slo en ingls, lo cual puede suponer un problema para algunos de los usuarios. La interfaz de algunas aplicaciones no est traducida o su traduccin es incompleta. En estos casos se puede considerar la edicin de una documentacin 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 estndares abiertos. Responsabledelaformacin La formacin puede realizarse dentro de la propia organizacin, en colaboracin con una empresa externa o a travs de una plataforma de aprendizaje en lnea.
FUOC P08/M2104/00604
100
En cualquiera de los casos, es importante facilitar tanto como sea posible el acceso a la formacin y a sus materiales. Segn la poltica de la organizacin, la asistencia a las actividades de formacin puede ser obligatoria o no. Las plataformas de aprendizaje en lnea ofrecen la ventaja que los usuarios pueden ajustar el proceso de aprendizaje y su acceso a la formacin de acuerdo con sus necesidades. Moodle es un sistema de gestin de cursos libre que permite crear lo que se denominan comunidadesdeaprendizajeenlnea, en la cual los alumnos pueden seguir la formacin y comunicarse entre ellos. Una buena opcin puede ser la combinacin de formacin presencial y un sistema de aprendizaje en lnea. Finalmente, no se tiene que descartar el ofrecer algn tipo de incentivo a los usuarios para motivarlos a participar en la formacin, por ejemplo la concesin de certificados de asistencia y de aprovechamiento. Tiposdeusuarios Los usuarios no son todos iguales. En primer lugar, hay siempre algunos usuarios que son ms receptivos hacia el nuevo software que otros. No obstante, en la mayora de los casos, una vez los usuarios han superado sus reservas hacia el uso del software libre lo encuentran muy similar al software propietario y estn satisfechos con su utilizacin. 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 tcnico y no tcnico necesitar una formacin y un seguimiento diferente. El personal tcnico 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 estn habituados a trabajar con un sistema de propiedad que, en cambio, dominan perfectamente. Por otra parte, la participacin del personal tcnico es muy importante para asegurar el funcionamiento del sistema una vez implantado. Una buena prctica es motivarlos y hacerlos partcipes del proceso de implantacin, de manera que puedan hacer suyo el sistema mientras ste se va poniendo en marcha. 2.8.2. Introduccin del software libre
Al margen de la formacin, otra de las prcticas que pueden facilitar el xito de un proyecto de migracin de software libre es introducir las nuevas aplicaciones y servicios gradualmente, de manera que los usuarios tengan tiempo de ir habitundose al nuevo entorno y no se encuentren con un sistema totalmente desconocido.
FUOC P08/M2104/00604
101
Instalacindeaplicacionespuente Hay un buen nmero de aplicaciones de escritorio cuyo uso est muy extendido y que estn disponibles tanto en sistemas operativos de propiedad como en GNU/Linux, como el paquete ofimtico OpenOffice.org, el navegador Firefox o el cliente de correo electrnico Thunderbird. Hay tambin 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 migracin y evaluar la respuesta de los usuarios y precisar mucho mejor sus necesidades de formacin. Migracinescalonadadelosservicios El primer objetivo de toda migracin es conseguir una transicin 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 migracin en los servidores, de manera que los usuarios puedan continuar trabajando normalmente hasta que el sistema est preparado para la migracin de los clientes. Entre los servicios que se pueden migrar fcilmente 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 tecnolgicas que funcionen bien en sistemas heterogneos, como OpenLDAP combinado con Samba. De esta manera se dispone tambin de bastante tiempo para formar al personal tcnico, el apoyo del cual puede ser muy til a la hora de migrar los clientes y dar soporte al resto de usuarios. Tanto la introduccin de aplicaciones puente como la migracin escalonada de servicios se tendrn que tener en cuenta en la planificacin del proyecto. 2.8.3. Comunicacin del proyecto
34 (34)
Sera una migracin de aplicaciones sencilla, como la que se ha visto en el apartado sobre tipos de migracin.
Como se ha visto, la implantacin y migracin a un sistema basado en software libre es un proceso que implica a todos los usuarios de la organizacin, y no slo al personal tcnico encargado de su despliegue y mantenimiento. Es esencial disponer de mecanismos eficaces de comunicacin entre los usuarios y la direccin tcnica y administrativa de la organizacin y garantizar la transparencia de todo el proceso, por lo que las actividades de comunicacin tienen que estar definidas en el plan de proyecto, que tiene que incluir: Comunicacininicialconjuntaatodoslosusuarios. Se explicar la motivacin y la planificacin general del proyecto antes de su puesta en mar-
FUOC P08/M2104/00604
102
cha a travs de reuniones informativas, notas o correos electrnicos internos o anuncios en la intranet de la organizacin. Comunicacinperidicadelavancedelproyecto. Se indicarn qu partes del sistema se migrarn y cundo, as como las eventuales modificaciones del proyecto. Se organizarn reuniones reducidas con los usuarios implicados en cada una de las fases de la migracin. Reunionesperidicasdespusdelafinalizacindelproyecto. Se evaluar el xito del proyecto y se har un seguimiento general de sus resultados, 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 gestin de incidencias a disposicin de los usuarios, de manera que puedan resolver tanto sus dudas como los problemas tcnicos derivados de la situacin. Es importante dar una respuesta rpida y eficaz a todos estos problemas, sobre todo en los primeros momentos despus de la implantacin. A la hora de disear un sistema de soporte al usuario, hay que responder estas preguntas, que definirn las caractersticas principales del sistema: Quines son los usuarios? Cmo funciona la organizacin? Qu tipo de soporte necesitan los usuarios? Qu tipo de soporte se ofrecer a cada tipo de usuario? Cunto soporte se ofrecer? Cmo se ofrecer el soporte?
La realizacin de pruebas piloto puede servir como base para caracterizar la mayora de los problemas con que se encontrarn los usuarios, y as preparar un procedimiento para resolver cada uno de ellos. De la misma manera, se tendrn que identificar los servicios y los usuarios ms importantes y crticos del sistema, que disfrutarn de un soporte preferente. Por otra parte, hay que tener en cuenta que ms soporte representa un coste ms elevado. Est la posibilidad de sobredimensionar el soporte en las primeras semanas despus de la migracin, cuando el nmero de consultas y de incidencias sea mayor. En cualquier caso, la clave para que un sistema de soporte al usuario sea eficaz es garantizar una comunicacin fluida con los usuarios, de manera que stos sean conscientes de que su problema se tiene en cuenta.
FUOC P08/M2104/00604
103
Finalmente, es posible que antes de la migracin ya existiera un sistema de soporte al usuario. En caso de que este sistema estuviera basado en software propietario, habra que evaluar las diferentes alternativas libres disponibles.
Pgina web Existen numerosas soluciones. Se puede consultar una comparacin en http://en.wikipedia.org/wiki/Comparison_of_tickettracking_systems.
FUOC P08/M2104/00604
104
3. La empresa del software libre
Esta tercera unidad de la asignatura de "Implantacin de sistemas en software libre" proporciona las bases para conocer los principales conceptos y caractersticas ligados al negocio empresarial del software libre. Desde sus inicios, el software libre siempre ha estado presente a nivel de las tecnologas de la informacin. Su evolucin a lo largo del tiempo se ha visto influida por los cambios estructurales que se han ido produciendo a nivel tecnolgico, econmico y social. Con el paso del tiempo, se han puesto de manifiesto las diferentes filosofas en torno a la creacin, produccin y difusin del software. En trminos generales, hay que destacar dos tendencias principales con caractersticas opuestas: Por un lado, la filosofa propietaria, que defiende la proteccin del software con el cierre y privatizacin del cdigo fuente, as como la imposicin de licencias con fuertes restricciones para su utilizacin. Por otra parte, la filosofa libre, que defiende la libertad del software y del cdigo fuente con licencias que garantizan los derechos de los usuarios en la ejecucin del programa, el estudio y la adaptacin del cdigo fuente y la redistribucin y la publicacin de las mejoras que se puedan introducir. Estas dos filosofas han generado modelos de negocio empresarial opuestos en la ideologa, el funcionamiento, la operativa y la economa: El modelo de software privativo normalmente establece un valor econmico que hay que sufragar mediante el uso restringido de una copia en formato binario, hecho que imposibilita la adaptacin, correccin o mejora del cdigo fuente por parte de personas u organizaciones que no disponen de los derechos de autora, o del acuerdo explcito de los que los poseen. Hay que destacar que muchas licencias propietarias impiden ceder los derechos de utilizacin a un tercero sin el previo acuerdo de los poseedores de los derechos de autora. El modelo de software libre tiende a centrarse en el desarrollo y la adaptacin 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 tambin Con el fin de conocer ms aspectos histricos del software libre, consultad el segundo punto de los materiales de la asignatura de "Introduccin al software libre".
FUOC P08/M2104/00604
105
La particular concepcin filosfica del software libre no slo influye directamente en el modelo de negocio y en la estrategia empresarial, sino tambin en la definicin, la gestin, la organizacin y el funcionamiento de la empresa tecnolgica. 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 clsico de forma sustancial. El primer apartado de esta unidad se dedica a caracterizar a los diferentes modelos de negocio basados en el software libre, vlidos y viables para ser llevados a la prctica como estrategia empresarial. El segundo apartado se dedica ntegramente a la concepcin del plan de negocio empresarial y se detallan los principales aspectos ligados a la creacin, organizacin, produccin y funcionamiento de la empresa del software libre. El tercer apartado presenta la produccin de software libre, con la caracterizacin de las principales particularidades en la creacin, organizacin, comunicacin y desarrollo del cdigo fuente. Finalmente, esta unidad dispone de dos anexos en los cuales se presentan de forma breve y sistemtica las principales licencias libres y estndares abiertos que tienen relacin directa con el negocio del software libre. 3.1. Modelos de negocio En este primer apartado se presentan los principales modelos de negocio basados en el software libre, as como las caractersticas y particularidades que lo diferencian de las tendencias de negocio basadas en software propietario.
En general, la diferencia ms 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 aqul que posee los derechos de autora) establece los derechos y deberes de los usuarios del producto y el escenario en el cual los pueden utilizar.
En este sentido, las licencias libres35 se basan en cuatro principios bsicos de libertad con respecto al software y su cdigo fuente: La libertad de ejecutar el programa con cualquier propsito. La libertad de estudiar el cdigo fuente y adaptarlo a las necesidades particulares, por lo cual es necesario el acceso al cdigo fuente.
(35)
Existe una cierta controversia entre la Free Software Foundation (http://www.fsf.org) y la Open Source Initiative (http:// www.opensource.org) a causa de las implicaciones de los trminos libre y abierto.
FUOC P08/M2104/00604
106
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 cdigo fuente.
Recurso web Encontraris la definicin original de software libre en http://www.gnu.org/philosophy/free-sw.html.
Los principios bsicos de libertad del software libre se contraponen al modelo privativo centrado en la explotacin comercial de venta de licencias de utilizacin restringida del formato binario , 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 organizacin 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/
36 (36)
En ingls, right-to-use licensing.
La apertura filosfica del software libre favorece los modelos de negocio centrados en el capital humano, los conocimientos, la personalizacin y la adecuacin de los productos, as como la evolucin constante del software. En este sentido, es importante destacar el papel que juega la comunidad de usuarios del software libre, que vela por la calidad y por la evolucin de los productos libres, con un rendimiento difcilmente igualable en modelos de propiedad. Con el tiempo, el modelo del software libre ha consolidado una oferta que abarca la mayora de sectores con presencia de software privativo, y ofrece un mercado maduro, cualitativo y seguro sobre el cual basar una estrategia empresarial, tanto para el desarrollo de software como para los servicios complementarios.
Recursos web En http://freshmeat.net/ y http://sourceforge.net/ encontraris un amplio abanico de proyectos de software libre en las principales reas de aplicacin de la tecnologa.
En cierta manera, la estrategia de negocio del software libre se fundamenta en los aspectos diferenciadores con respecto al modelo de propiedad, por ejemplo la ampliacin de funcionalidades, la adaptacin personalizada, el elevado y constante nmero de revisiones, las garantas 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.
FUOC P08/M2104/00604
107
En los siguientes apartados se presentan los principales modelos de negocio que se derivan de la filosofa conceptual del software libre: desarrollo, consultora, instalacin e integracin, migracin, mantenimiento y soporte y formacin. Los modelos de negocio que se presentan no deben entenderse como independientes, sino como complementarios. Es decir, puede convenir la combinacin de dos o ms 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 produccin total o parcial de un producto basado en software libre destinado a su comercializacin, ya sea directamente o bien en el marco de un proyecto de implantacin por cuenta ajena, como los presentados en la segunda unidad de la asignatura.
La definicin 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 caractersticas de las licencias libres convierten esta posibilidad en una opcin secundaria, aunque sobradamente utilizada por algunas organizaciones.
Productos libres empaquetados Algunas organizaciones deciden ofrecer sus productos libres empaquetados (caja, discos, manuales, documentacin, 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 distribucin Ubuntu en http://www.ubuntu.com/getubuntu/purchase.
En general, la produccin de software libre responde principalmente a la venta de servicios complementarios de valor aadido para el cliente, que tambin sirven para sustentar la continuidad del software, por ejemplo la personalizacin y adecuacin a un entorno determinado. En los materiales de la asignatura de "Introduccin al software libre" se ofrece una clasificacin de las posibles alternativas del desarrollo de software libre, reproducida brevemente a continuacin: Mejor conocimiento. Se basa en el propsito de rentabilizar el conocimiento sobre uno o ms productos libres, ofreciendo desarrollos a medida, modificaciones o adaptaciones (entre otros que se presentarn ms adelante). La participacin activa en la creacin y desarrollo de los productos libres es el valor aadido de la empresa ante el cliente y la competencia. Mejor conocimiento con limitaciones. Se basa en el modelo anterior (mejor conocimiento) pero con una implementacin mixta de licencias libres y de propiedad (o eventualmente patentes) para reducir la compeVed tambin Encontraris ms informacin y ejemplos de esta clasificacin en el apartado 5.2 "Modelos de negocio basados en software libre" de los materiales de la asignatura de "Introduccin al software libre".
FUOC P08/M2104/00604
108
tencia. Este modelo puede resultar inviable si el producto libre se escinde en una rama soportado por la comunidad libre, de manera que podra desaparecer la ventaja competitiva. Fuentedeunproductolibre. Es similar al primer modelo (mejor conocimiento) con la diferencia que la empresa es la productora del cdigo de forma casi ntegra. El cliente valora el posicionamiento y la ventaja competitiva con respecto a la competencia. Este modelo recibe el soporte de la comunidad libre. Fuentedeunproductoconlimitaciones. Se basa en el modelo anterior (fuente de un producto libre) pero con una implementacin orientada a reducir la competencia, por ejemplo iniciando la distribucin bajo licencia privativa y liberndose ms adelante, o haciendo que la distribucin inicial se limite a los clientes de la empresa. Licenciasespeciales. Se basa en la produccin 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 integracin con otros productos propietarios. Ventademarca. Se basa en la distribucin de productos libres con una imagen de marca empresarial, que da calidad y valor aadido desde el punto de vista del cliente. Normalmente, estos productos se acompaan de numerosos servicios adicionales a los clientes. La seleccin de la tipologa de negocio asociada al desarrollo de software tiene que coordinarse principalmente con la estrategia empresarial y el mercado objetivo. En este sentido, una organizacin puede decidir usar una tipologa personalizada para cada uno de los productos que pretenda introducir en el mercado, en funcin de la estrategia y el mercado objetivo particular que persiga en cada uno de ellos. El modelo de negocio de desarrollo de software libre tambin exige la seleccin esmerada de las licencias del cdigo fuente que manipula: La licencia del cdigo fuente que modifica, si el producto final es una mejora de un producto que ya exista antes. La licencia del cdigo fuente que enlaza, si el producto final requiere para su operativa implementar llamadas en funciones de bibliotecas externas. La licencia del cdigo fuente que crea, es decir, cuando el cdigo fuente es completamente nuevo.
FUOC P08/M2104/00604
109
La licencia del cdigo fuente del producto final, que considera el conglomerado de cdigo fuente del producto final.
La importancia de determinar esmeradamente la licencia asociada a cada parte del cdigo fuente que se manipula radica en la existencia de diferencias entre las diversas licencias libres. Es decir, aunque todas las licencias libres garantizan las cuatro libertades bsicas, difieren en la poltica de licenciamiento de la redistribucin de cdigo modificado, que es precisamente el objeto del modelo de negocio de desarrollo de software libre. En el anexo I de esta unidad presentamos brevemente las caractersticas ms importantes de las principales licencias del software libre y exponemos la poltica de redistribucin y las compatibilidades del enlace y de la obra derivada. La seleccin y combinacin adecuada de licencias influye directamente en la produccin de software libre, y puede tener implicaciones legales si no se realiza esmeradamente. En el ltimo apartado de esta unidad, dedicado a la produccin de software libre, se profundizar en la seleccin de la licencia ms adecuada a partir de los parmetros del producto. Finalmente, hay que decir que el software libre promueve y utiliza especificaciones pblicas, denominadas estndares abiertos, con el fin de favorecer la universalidad y la interoperabilidad de los formatos que manipulan. En el anexo II de esta unidad didctica presentamos brevemente las principales caractersticas y ejemplos de los estndares abiertos. 3.1.2. Consultora
El modelo de negocio de consultora se basa en la produccin de servicios profesionales complementarios al software libre para usuarios y organizaciones.
En cierta manera, este modelo de negocio se centra en el objetivo de proveer servicios tecnolgicos profesionales externos de calidad a organizaciones que no asumen totalmente la creacin, la gestin, el desarrollo y la evaluacin de sus proyectos tecnolgicos internos. La diversidad de servicios profesionales que pueden ofrecer las consultoras es elevado, y depender de la estrategia y el entorno a actividad empresarial. Sin embargo, tienen una fuerte relacin con las actividades de estudio, anlisis, diseo y evaluacin propias del proyecto de implantacin de sistemas de software libre presentado en la segunda unidad de este mdulo.
Ved tambin En el apartado "Clasificacin por mbito" de la primera unidad encontraris ms informacin de la tipologa de proyectos productivos.
FUOC P08/M2104/00604
110
A continuacin, presentamos una clasificacin breve de los principales servicios que una consultora puede ofrecer a sus clientes: Gestin de proyectos: se basa en el propsito de realizar las funciones de creacin y gestin funcional del proyecto de implantacin de software libre. Las tareas que desarrolla este servicio se relacionan con el ciclo de vida del proyecto, la gestin 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 coordinacin, informacin, gerencia y seguimiento del proyecto. Ejecucindeetapasdeanlisisydiseodelproyecto: se basa en el propsito de realizar una o ms etapas de anlisis y diseo del proyecto de implantacin de un sistema en software libre. Las tareas que desarrolla este servicio se relacionan con los encargos de la contratacin, por ejemplo el estudio del sistema actual, el estudio de requerimientos del nuevo sistema, el anlisis de soluciones en software libre y/o el diseo de un nuevo sistema, de acuerdo con las etapas presentadas en la segunda unidad del mdulo. Evaluacinyauditora: se basa en el propsito de realizar valoraciones tecnolgicas profesionales de una o ms caractersticas de sistemas en funcionamiento. Las tareas que desarrolla este servicio pueden estar enmarcadas dentro de un proyecto de implantacin de sistemas, como sera el caso de la ejecucin de etapas visto anteriormente, pero tambin se pueden desarrollar de forma independiente y aislada. La evaluacin o la auditora se centra en valorar uno o ms aspectos del sistema, como la seguridad, el rendimiento, la eficiencia o la eficacia (entre otros), y se puede realizar antes y/o despus de la implantacin del sistema. Asesora: se basa en el propsito de dar soporte, ayuda y consejo profesional a la toma de decisiones tecnolgicas en la organizacin. Las tareas que desarrolla pueden tener lugar antes del inicio de cualquier proyecto de implantacin o bien en las fases de estudio, anlisis y diseo, pero se enmarcan en el soporte profesional a decisiones estratgicas tecnolgicas para el futuro de la organizacin. La lista presentada no se tiene que considerar ni exhaustiva ni excluyente, ya que el modelo de negocio puede estructurar dos o ms servicios para responder a la estrategia empresarial. Adicionalmente, el modelo de negocio de consultora puede combinarse con otros modelos de negocio para ofrecer al cliente un servicio tecnolgico integral.
Ampliando informacin En el apartado "Tipologia de proyectos" de la primera unidad y en el apartado "Ciclo de vida" de la segunda unidad encontraris ms informacin sobre la gestin y el ciclo de vida de los proyecto de software libre.
Ved tambin En los apartados "Estudio de la situacin actual", "Estudio de los requisitos de la implantacin", "Anlisis de las soluciones en software libre" y "Desarrollo" de la segunda unidad encontraris ms informacin sobre el estudio del sistema actual, el estudio de requerimientos del sistema, el anlisis de las soluciones en software libre y el diseo del sistema, respectivamente.
FUOC P08/M2104/00604
111
En este sentido, el mejor conocimiento de las plataformas tecnolgicas implantadas (o que hay que implantar), as como la excelencia para el anlisis y extraccin de informacin y conclusiones, o el alcance y la complejidad del proyecto, son caractersticas decisorias a fin de que la organizacin decida externalizar la gestin o las etapas de la implantacin. Normalmente, los trabajos de consultora se formalizan con contratos abiertos o cerrados. En los contratos abiertos la relacin se origina a partir del encargo de un servicio determinado y, en funcin del resultado del servicio, el contrato se ampla con el encargo de nuevos servicios. Por ejemplo, la ejecucin de una o ms etapas del proyecto puede estar sujeta a contratos abiertos. En cambio, en los contratos cerrados se adjudica el cumplimiento de un determinado objetivo, funcin, resultado o trabajo, sin posibilidad directa de ampliar la contratacin en el mismo escenario. Por ejemplo, la auditora independiente de un sistema puede estar sujeta a contratos cerrados, dadas las eventuales caractersticas temporales de puntualidad y aislamiento. 3.1.3. Instalacin e integracin
El modelo de negocio de instalacin e integracin se basa en la implantacin directa de sistemas en software libre para usuarios y organizaciones, normalmente enmarcados en proyectos de software libre.
En cierta manera, este modelo de negocio considera el software libre como objeto para la produccin de servicios, ms que como producto en s mismo. De esta forma, se fundamenta un mercado en el cual se resaltan los beneficios para el cliente: La organizacin no tiene que pagar licencias en productos de software libre que se distribuyen de forma gratuita y, por consiguiente, puede reducir el coste de implantacin tecnolgica. La organizacin no tiene que recurrir a la piratera de productos y, por consiguiente, no incumplir la legalidad vigente. La organizacin puede adaptar directamente las soluciones libres y, por consiguiente, podr disminuir el coste de implantacin de sistemas especializados. La organizacin puede adoptar paquetes integrados de implantacin directa y, por consiguiente, reducir el riesgo de implantacin tecnolgica.
FUOC P08/M2104/00604
112
A continuacin 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: Configuracin: se trata de realizar las tareas de configuracin y ajuste37 de un sistema ya implantado con el objetivo de formalizar la configuracin inicial, mejorar su rendimiento o ajustarlo a nuevos propsitos no considerados inicialmente. En cualquier caso, los ajustes que se introducen no modifican el cdigo fuente de la aplicacin, nicamente la configuracin de aquellos componentes que permitan el ajuste a las caractersticas particulares de la instalacin. Pruebas: se trata de proporcionar un banco de pruebas de sistemas, aplicaciones o soluciones en software libre bajo una perspectiva determinada. Puede tratarse de un anlisis comparativo de soluciones libres, las pruebas de un nuevo diseo de sistema, o el test de software de implantacin directa sobre hardware especfico, ya sea en el marco de un proyecto de implantacin, o bien como pruebas independientes y aisladas. Integracin: se trata de realizar y/o comprobar la integracin entre dos o ms soluciones de software libre, con el objetivo de proporcionar un paquete nico que resuelva una funcin operativa concreta38. Normalmente, esta integracin se puede resolver con la configuracin apropiada de cada elemento y, eventualmente, con algn componente adicional que permita la integracin con ms eficiencia.
(38) (37)
En ingls, set-up o tune-up.
Ampliando informacin En los apartados "Anlisis de las soluciones en software libre", "Desarrollo" e "Implantacin y migracin" de la segunda unidad encontraris ms informacin sobre el anlisis de las soluciones en software libre, el diseo del sistema y la implantacin y migracin del sistema, respectivamente.
Por ejemplo, LAMP (Linux, Apache, MySQL, PHP) es un paquete integrado de software con diferentes objetivos particulares, pero que conjuntamente soluciona una problemtica concreta de forma eficiente y eficaz.
(39)
Instalacin: se trata de realizar la instalacin masiva de software de implantacin directa en mquinas clientes o servidores . Este servicio puede necesitar la configuracin y el ajuste tanto del software libre que se pretende instalar como del hardware receptor de la instalacin. Tambin puede ser necesaria la integracin de las diferentes soluciones que se pretenden instalar. En los casos en los cuales se tenga que implantar el mismo software en un conjunto de ordenadores con idntico hardware, puede resultar til usar software de clonado y distribucin de imgenes preconfiguradas para ahorrar tiempo y coste, adems de mejorar la eficiencia y eficacia del proceso.
39
En ingls, sera similar al trmino installfest, pero aplicado al negocio estructurado.
Distribucin: se trata de redistribuir software libre a los clientes, ya sea en el format original
40
(40)
o bien en configuraciones personalizadas en relacin
con el mbito de negocio empresarial; por ejemplo la integracin de herramientas, la orientacin operativa a cliente, a servidor o a estacin de trabajo41, entre otros. La redistribucin 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.
En http://freshmeat.net/ y http://sourceforge.net/ encontraris un amplio abanico de proyectos de software libre en las principales reas de aplicacin de la tecnologa.
(41)
En ingls, workstation.
FUOC P08/M2104/00604
113
Tal como se desprende de la clasificacin anterior, estos servicios tienen una fuerte relacin con las etapas de anlisis de las soluciones en software libre y de implantacin y migracin del proyecto de implantacin presentado en la segunda unidad. En este sentido, el mejor conocimiento de las plataformas tecnolgicas, as como la excelencia y eficiencia de los servicios, o el alcance y la complejidad del proyecto, son caractersticas decisorias a fin de que la organizacin decida externalizar la instalacin y la integracin del sistema. 3.1.4. Migracin de sistemas
El modelo de negocio de migracin 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 migracin es un proceso complejo, que hay que ejecutar con la precisin y el rigor necesarios de acuerdo con la importancia que suponen los datos y configuraciones como capital para la organizacin. La diversidad de situaciones con que se pueden encontrar las empresas que se dedican a la migracin de sistemas son fruto de la combinacin entre las plataformas de origen y de destino de la migracin. El conocimiento profundo de las plataformas y la experiencia en la migracin fundamentan el valor aadido para el cliente. A continuacin 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 tambin En el apartado "Implantacin y migracin" de la segunda unidad encontraris sobradamente detalladas las caractersticas de la migracin de sistemas. Concretamente, en el apartado "Migracin de los servicios de un sistema" encontraris ms informacin de los servicios que aqu presentamos.
Servicios de sistema de ficheros, tanto de servidor como de clientes. Servicios de impresin, tanto entre clientes como entre servidores. Servicios de directorio y de autentificacin centralizada. Servicios de red, especialmente de protocolos de gestin automatizada de control de la red, de las comunicaciones y de los clientes.
Gestin y administracin del sistema, tanto la gestin de la red como del software.
FUOC P08/M2104/00604
114
Servicios web, tanto con plataformas estticas como dinmicas. Bases de datos, tanto la migracin de los datos como la verificacin de los accesos.
Entornos de escritorio y aplicaciones de ofimtica, 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 migracin, 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 tecnolgicas de origen y de destino de la migracin son caractersticas decisorias a fin de que la organizacin decida externalizar la migracin del sistema. Tal como se puede concluir de la clasificacin de los servicios que hemos presentado, el proceso de migracin puede necesitar otros servicios, como la instalacin, la configuracin, la integracin o las pruebas para asegurar la consecucin de los objetivos. El software libre utiliza y fomenta los estndares abiertos para el intercambio interoperable de los datos y es especialmente relevante su papel en la migracin de los sistemas. Por ejemplo, partir de un sistema que no almacene los datos en estndares abiertos podra complicar la migracin a causa de la conversin de los formatos, especialmente si el original es privativo. En el anexo II de este mdulo didctico presentamos los estndares abiertos, su definicin, los organismos que los impulsan y algunos ejemplos. 3.1.5. Administracin y mantenimiento de sistemas
El modelo de negocio de administracin y mantenimiento de sistemas se basa en realizar las tareas de gestin y seguimiento de un sistema ya implantado y en funcionamiento.
El principal objetivo de los servicios que puede ofrecer este modelo de negocio es mantener funcional todo el sistema a lo largo del tiempo, ajustando la configuracin a los cambios que se produzcan, solucionando problemticas que puedan surgir y reparando las averas que impidan el funcionamiento habitual de la organizacin.
FUOC P08/M2104/00604
115
A continuacin 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: Administracin: consiste en proporcionar la gestin principal del sistema, el ajuste necesario con el paso del tiempo, la supervisin del funcionamiento, la implantacin de nuevas funcionalidades y la evolucin del sistema. Muchas de las tareas de administracin del sistema se pueden ejecutar de forma remota . Mantenimiento y evolucin: consiste en proporcionar supervisin, seguimiento y correccin de las incidencias que se puedan originar en el sistema y que impidan su funcionamiento, as como el control y evolucin de la obsolescencia de los componentes. Por ejemplo, las averas y la desconfiguracin de hardware o de software, el control y actualizacin de versiones de software, o el plan de evolucin de hardware y software. Seguridad: consiste en proporcionar la gestin de la seguridad del sistema, controlando los riesgos, manteniendo polticas de prevencin, contingencia, diagnstico y correccin de fallos. Por ejemplo, copias de seguridad o el control y mantenimiento de claves y certificados. Dadas las caractersticas y particularidades de estos servicios, muchas organizaciones deciden mantener trabajadores en plantilla que realicen estas tareas, pero algunas organizaciones pequeas o medias no tienen bastante capacidad para asumir esta figura. Tambin hay que tener en cuenta que la externalizacin de algunos servicios, como servidores de intranet y de extranet, pueden motivar la contratacin de servicios externos de administracin 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 formacin
Intranet y extranet Los servicios web, de intranet o de extranet son fcilmente externalizables gracias a la proliferacin de los hoteles de datos (Data Hotels) o centros de datos (Data Centers).
42 (42)
Por ejemplo, el uso conjunto de ssh, cron y at.
El modelo de negocio de soporte y formacin consiste en proporcionar ayuda tcnica profesional para la educacin y aprendizaje tecnolgico de usuarios y la resolucin de incidencias y problemas relacionados con la explotacin del sistema.
La implantacin de sistemas en software libre puede necesitar medidas de soporte y formacin a los usuarios durante los primeros momentos de utilizacin, especialmente si el sistema anterior estaba basado en software privativo. Tal como se ha visto en el segundo mdulo de la asignatura, el proyecto de implantacin tiene que tener en cuenta la necesidad de actuar en el aprendi-
FUOC P08/M2104/00604
116
zaje de los usuarios para favorecer la gestin del cambio, el cual, junto con sus particularidades, hace que acabe siendo un servicio fcilmente externalizable a empresas especializadas en este sector. A continuacin 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: Formacin: se propone proporcionar educacin y aprendizaje sobre herramientas de software libre a usuarios finales, por ejemplo sistemas operativos o herramientas de ofimtica. Este servicio tambin puede incluir la formacin de software especializado resultante del desarrollo producido en el proyecto de implantacin de sistemas, por lo que puede resultar conveniente para la gestin del cambio coordinar los esfuerzos con el equipo de implantacin. Soporte: se propone proporcionar asistencia tcnica a los usuarios ante problemas cotidianos. Muchos de estos servicios se implementan en centros telefnicos de ayuda43, aunque tambin puede resultar til ofrecer buzones de correo electrnico para la resolucin de incidencias o mensajera instantnea44 con un profesional. Tambin puede resultar conveniente combinar los esfuerzos con el equipo del proyecto de implantacin de sistemas con el fin de resolver posibles errores del software implantado. En general, este modelo de negocio pide recursos humanos, tecnolgicos y materiales adecuados a los objetivos de la formacin: Recursos humanos con conocimientos profundos de la temtica y con capacidad para transmitir los conocimientos y resolver problemas. Recursos tecnolgicos adecuados a la formacin y el soporte, por ejemplo plataformas tecnolgicas de ayuda a la educacin o centros telefnicos de asistencia tcnica. Recursos materiales adecuados a la formacin, como documentacin y manuales especficos de software libre
45 (45) (44) (43)
Ved tambin En el apartado "Formacin, comunicacin y soporte al usuario" de la segunda unidad encontraris ms informacin sobre la formacin y el soporte al usuario.
En ingls, call centers.
En ingls, instant messaging o chat.
Recurso web Por ejemplo, Moddle es una plataforma de educacin a distancia basada en software libre. http://moodle.org/.
bajo licencias libres.
La calidad de estos parmetros es fundamental a fin de que la organizacin decida externalizar los servicios de formacin y soporte. Normalmente, los servicios de formacin se contratan por cursos con estructura acordada previamente, mientras que los servicios de soporte se contratan por cuotas mensuales o anuales, con acuerdo previo de los servicios cubiertos.
El proyecto SELF proporciona una plataforma europea para crear y compartir materiales educativos relacionados con el software libre y los estndares abiertos (http:// selfproject.eu/).
FUOC P08/M2104/00604
117
3.2. Plan de empresa
Ved tambin En el apartado 10.2 "Licencias de otros recursos libres" del material de la asignatura de Introduccin al software libre encontraris dos licencias de documentacin, materiales y obras literarias sobradamente utilizadas en la actualidad.
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.
Aclaracin En este apartado se utilizar preferentemente el trmino plan de empresa, ya que el objetivo del apartado es presentar los elementos necesarios para la creacin 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 definicin, los objetivos del plan de empresa son los siguientes: Realizar un estudio de mercado que posicione el proyecto empresarial y determine su viabilidad tcnica, econmica y financiera Desarrollar las medidas necesarias para conseguir los objetivos fijados en el mismo plan de empresa Realizar un seguimiento de la evolucin de la empresa y evaluar las desviaciones respecto al plan de empresa inicial Servir como tarjeta de presentacin del proyecto y de los emprendedores a fin de obtener financiacin y apoyo de terceros Si bien los tres primeros objetivos son principalmente de uso interno, el ltimo es de uso externo y visible por personas ajenas al proyecto, al menos en principio. Durante la preparacin de un plan de empresa hay que tener en cuenta siempre esta doble finalidad: servir como plan de proyecto y, a la vez, como presentacin del proyecto. Por supuesto, hay que evitar la tentacin de omitir los riesgos o aspectos negativos del proyecto a fin de hacerlo ms atractivo a los inversores. De hecho, la falta de estos elementos podra volverse en contra del propio proyecto empresarial, ya que estara basado sobre supuestos falsos. Por ello, la veracidad de los aspectos tcnicos y econmicos es uno de los requisitos bsicos a la hora de redactar un plan de empresa.
FUOC P08/M2104/00604
118
Todo plan de empresa debe responder a una serie de preguntas sobre el proyecto que se desea poner en marcha: quin?, qu?, por qu?, dnde?, cundo? y cunto? Quin? El nombre de la empresa, la marca de los productos o servicios ofrecidos, los nombres y trayectoria de los promotores. Qu? La descripcin 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. Porqu? En general, todo plan de empresa busca obtener y maximizar los beneficios econmicos. Sin embargo, esto no es incompatible con otros objetivos como la mejora de la calidad de vida de la sociedad o la creacin de empleo. Dnde? La zona geogrfica en la que se van a comercializar los productos o servicios, por ejemplo regional, nacional o internacional. Los canales de distribucin que se van a utilizar, incluyendo los posibles acuerdos con otras empresas que permitan acceder a otras regiones. Cundo? El inicio previsto de la actividad empresarial y su planificacin posterior, incluyendo condiciones o limitaciones temporales que puedan afectar a la empresa, como los trmites de obtencin de licencias, el tiempo de produccin, la obsolescencia de determinadas tecnologas o la estacionalidad. Cunto? La inversin inicial necesaria para poner en marcha el proyecto empresarial, la facturacin mnima necesaria y la deseada, el umbral de beneficios y prdidas, la reinversin de los beneficios y la reparticin de dividendos, entre otros. Estas cuestiones se traducen en los siguientes aspectos que se encuentran en casi todo plan de empresa: Resumen ejecutivo Introduccin Descripcin del negocio Organizacin de la produccin
FUOC P08/M2104/00604
119
Organizacin interna y recursos humanos Estudio de mercado Plan de marketing Anlisis econmico-finaciero Forma legal Gestin de riesgos Resumen y evaluacin
Dependiendo de la naturaleza de la empresa o negocio cada uno de estos aspectos tendr mayor o menor importancia en el plan de empresa y podr organizarse de diferentes maneras. En los apartados que veremos a continuacin se revisar cada uno de estos aspectos y se estudiar su relacin con los modelos de negocio basados en software libre vistos en el apartado anterior. 3.2.1. Resumen ejecutivo
(46)
El resumen o sumario ejecutivo es una nota breve que aparece al principio del plan de empresa y que resume los elementos principales del documento. De esta manera, permite que por ejemplo potenciales inversores puedan hacerse una idea completa del plan de empresa, sin necesidad de entrar en los detalles de cada uno de los apartados.
46
En cualquier caso, su extensin no debera superar las tres pginas.
El resumen ejecutivo debe repasar prcticamente todos los aspectos del plan de empresa, a saber: Descripcin del modelo de negocio, prestando especial atencin a la cadena de valor y la fuente de ingresos. Breve descripcin del los promotores del proyecto, su formacin, sus conocimientos y habilidades, su trayectoria profesional y su dedicacin al nuevo proyecto. Descripcin concisa del mercado, incluyendo tamao, clientes, potencial de crecimiento y barreras.
FUOC P08/M2104/00604
120
Anlisis de las reas funcionales del proyecto: produccin, calidad y organizacin de los recursos humanos.
Resumen del anlisis financiero del proyecto y de la inversin 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 promotor. 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. Introduccin
(47)
A continuacin del resumen ejecutivo y el ndice, el primer elemento del plan de empresa debe ser una introduccin que presente el nombre de la futura empresa47 y el equipo promotor, as como el resto de profesionales involucrados en la redaccin del plan de empresa.
En el caso de que el plan describa un nuevo producto o servicio de una empresa ya constituida, es conveniente presentar un resumen de su actividad, su evolucin histrica, su tamao, etc.
La presentacin del equipo promotor debe incluir, como hemos visto, el historial profesional de cada uno de sus miembros y los conocimientos que aportan al proyecto empresarial. Es bastante frecuente que una parte del equipo promotor tenga un perfil especializado en gestin empresarial, pero que tambin cuente con especialistas en determinadas reas tecnolgicas, como en el caso de las empresas que trabajan con software libre. Por ltimo, la introduccin debe proporcionar una breve descripcin de los diferentes apartados del plan de empresa que se desarrollarn posteriormente. Misin y visin La introduccin es un buen lugar para presentar la misin y la visin de la nueva empresa, de manera que el lector pueda comprobar como estos dos conceptos se desarrollan en el plan de empresa. La misin y la visin de una organizacin permiten definir de una manera concisa sus principales caractersticas y objetivos y las estrategias para llevarlos a cabo.
FUOC P08/M2104/00604
121
La misin consiste en una frase concisa que justifica la existencia de la organizacin, es decir el propsito bsico hacia el que apuntan sus actividades, y los valores que guan las actividades de sus empleados. La misin est fuertemente vinculada a los valores internos de la organizacin, y describe en buena medida cmo competir y generar valor al cliente. La visin es tambin una frase concisa que describe las metas a medio y largo plazo de la organizacin. La visin est orientada al mercado y debe expresar de una manera colorista y visionaria cmo quiere la organizacin ser percibida por el mundo.
Las principales diferencias entre misin y visin se resumen en lo siguiente: La misin describe los aspectos internos de la organizacin y su funcionamiento, mientras que la visin describe los aspectos externos. La misin tiene su horizonte en el corto y medio plazo, poniendo especial nfasis en los aspectos que se deben poner en prctica inmediatamente en la organizacin, mientras que la visin se fija a medio y largo plazo y da las lneas generales de la evolucin de la organizacin en el futuro.
Corcaribe Tecnologa y eZ Systems La empresa Corcaribe Tecnologa, especializada en productos y servicios basados en software libre, se fija la siguiente misin: "Corcaribe Tecnologa provee soluciones tecnolgicas que generan valor agregado bajo un modelo de negocio que permite ofrecer a sus clientes el mejor coste por los resultados entregados, produciendo autnticos beneficios tangibles e intangibles a sus miembros y colaboradores." Y la siguiente visin: "Convertirse en referencia latinoamericana de continuo xito en la implementacin de soluciones tecnolgicas 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 gestin de contenidos se propone la siguiente misin: "Ser la primera plataforma de gestin de contenidos en 2012." Y la siguiente visin: "Ayudar a las empresas a gestionar, publicar y compartir la informacin."
La definicin de una misin y una visin 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
3.2.3.
Descripcin del negocio
Es recomendable comenzar este apartado con una descripcin de la empresa que se desea crear y con una breve presentacin de los promotores del proyecto, aunque ya se haya realizado previamente en la introduccin.
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 atencin 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 proteccin 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 produccin y prestacin de servicios, lo que servir de introduccin al prximo apartado dedicado a la organizacin de la produccin. 3.2.4. Organizacin de la produccin
Dentro del plan de empresa, el apartado dedicado a la organizacin de la produccin aporta una descripcin de las tareas tcnicas de la futura empresa.
Hasta ahora se ha contemplado la posibilidad de que el plan de empresa o de negocio describa la comercializacin de un nuevo producto o servicio, indistintamente. Segn 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, produccin y posterior comercializacin de un producto, se describirn en detalle las fases de desarrollo y produccin.
FUOC P08/M2104/00604
123
En el caso de que la empresa se dedique a la prestacin de un servicio sin ningn proceso productivo, se describirn en detalle los procedimientos para la prestacin del servicio y las necesidades tcnicas.
Por supuesto, estos dos casos no son excluyentes y en un plan de empresa se pueden dar ambas. Por ejemplo, una empresa especializada en migracin de sistemas a software libre que tambin ofrece servicios de formacin en tecnologas basadas en software libre a usuarios y a personal tcnico. En general, la actividad empresarial que implica las fases de investigacin, desarrollo y produccin presenta una complejidad mucho mayor, y tambin mayores riesgos: Fasedeinvestigacinydesarrollo. La descripcin de la fase de investigacin y desarrollo debe prestar especial atencin a la estimacin de la duracin de la fase de investigacin y desarrollo y de las necesidades de inversin en recursos materiales y humanos. Especialmente en sectores de alta tecnologa, como es el caso del software libre, el plan de empresa debe evaluar la capacitacin de los recursos humanos y el know-how necesarios para el xito de las tareas de investigacin y desarrollo. Por otra parte, este apartado debe describir en detalle la distribucin de funciones y responsabilidades, los riesgos inherentes a toda actividad de investigacin y desarrollo, las potenciales sinergias entre proyectos, el proceso de innovacin y mejora continua de los productos y cmo este proceso va a integrarse en el proceso de produccin. 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 desenvolupament, les potencials sinergies entre projectes, el procs d'innovaci i millora continuada dels productes, i la manera com s'integrar aquest procs en el procs de producci. Fasedeproduccin. La descripcin del proceso productivo debe describir en primer lugar el ciclo operativo , la localizacin de las instalaciones de produccin, su coste y su accesibilidad. En segundo lugar, es necesario describir los locales, edificios y equipos necesarios para la produccin o prestacin de los servicios. Para cada uno de stos se deben presentar las modalidades de financiacin y adquisicin49, sus caractersticas, su disponibilidad, su duracin y su amortizacin anual. Se debe prestar especial atencin a la gestin de la calidad, con la descripcin de los estndares y certificaciones de calidad que se van a aplicar tanto a los procesos como a los resultados del proceso productivo.
(49) 48 (48)
Esto incluye la capacidad productiva en nmero de unidades y la produccin esperada, as como el personal y el nmero de horas o turnos necesarios para la produccin. Igualmente, se puede presentar los planes de expansin de las instalaciones y de adquisicin de nuevos equipos.
FUOC P08/M2104/00604
124
Finalmente, se debe dar una visin estratgica del proceso productivo, por ejemplo en el caso de que se subcontrate la produccin de algunos componentes o una parte del proceso productivo50. De nuevo, la descripcin 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, an ms cuando el lector puede no estar familiarizado con el software libre. Igualmente, es conveniente incidir en la calidad aadida 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. Organizacin interna y recursos humanos
Por ejemplo, un editor de software libre podra subcontratar la produccin del soporte de distribucin y del embalaje de sus programas.
Ampliando informacin En el apartado "Produccin de software libre" de la tercera unidad se estudian en detalle las particularidades del proceso de produccin de software libre.
Este apartado del plan de empresa concreta la organizacin del equipo de trabajo necesario para el desarrollo del proyecto empresarial y los perfiles necesarios.
En primer lugar, se debe incluir una descripcin de las funciones y puestos de direccin clave, junto a los perfiles necesarios e incluso el nombre y currculo51 de las personas que vayan a ocupar estos puestos en el caso de que ya estn decididas. En segundo lugar, se deben describir las diferentes categoras profesionales necesarias en la empresa, sus responsabilidades, las principales tareas que llevarn a cabo y la modalidad de contratacin, entre otros. Es conveniente indicar la remuneracin correspondiente a cada tipo de trabajadores ya ocupen cargos directivos o no. La organizacin interna de la empresa se puede representar fcilmente mediante un organigrama, por departamentos y reas de actividad y con las personas especficas, si existieran, en los puestos de direccin. Este apartado debe concluir con la descripcin de la poltica general de la empresa en el rea de recursos humanos y decidir si es necesaria la creacin de un departamento especfico de recursos humanos o la gestin de stos puede realizarse de forma distribuida en cada departamento.
(51)
Incluye su experiencia profesional, su especializacin y los principales logros en su carrera. Este tipo de informacin cumple una doble funcin: por un lado refuerza la confianza de los inversores potenciales y, por otro lado, permite descubrir las fortalezas y debilidades del equipo gestor.
FUOC P08/M2104/00604
125
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 libre52. Adems, 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 clsicos de director tcnico o director comercial, se pueden encontrar roles como director de comunidad, responsable de la gestin de las relaciones con los desarrolladores y usuarios de software libre o director de proyectos en cooperacin, responsable de la gestin y coordinacin de proyectos que se lleven a cabo en colaboracin con otras empresas, centros de investigacin o universidades. 3.2.6. Estudio de mercado
Por ejemplo, en el momento de la edicin de estos materiales, si bien el software libre es ya conocido y las tecnologas y soluciones basadas en l bastante populares, es difcil encontrar profesionales que hayan participado activamente en proyectos de software libre, ya sea como empleados en una empresa o por propia iniciativa.
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 tcnica y econmica 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 elaboracin de un plan de empresa es conveniente realizar el estudio de mercado en primer lugar, o al menos en una primera aproximacin, ya que sus resultados pueden afectar a diferentes partes del plan de empresa. As, el anlisis de mercado debe proporcionar informacin sobre los aspectos siguientes: Situacinactualdelmercado. En primer lugar, es necesario segmentar el mercado de acuerdo a las caractersticas ms relevantes en el plan de empresa y determinar su volumen, as como su evolucin histrica. Igualmente, hay que determinar el proceso de decisin en el mercado y el comportamiento de los clientes, en particular su reaccin ante la introduccin de nuevos productos o servicios. En segundo lugar, hay que evaluar las posibles necesidades que podra generar la introduccin 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 hbitos de los clientes. Previsionessobreelcrecimientodelmercado. Una vez se conoce el estado actual del mercado hay que ser capaz de realizar previsiones sobre su evolucin futura. Se trata de un mercado en crecimiento, estable o en
FUOC P08/M2104/00604
126
decadencia? Cul es el nivel de fragmentacin del mercado? Se est produciendo un proceso de concentracin? De nuevo, hay que tener en cuenta la influencia que los nuevos productos o servicios podran tener en el mercado. Por ejemplo, la introduccin de soluciones basadas en software libre puede efectivamente cambiar el mercado, al propiciar la formacin de un nuevo sector especializado en software libre. Identificacinyclasificacindelosclientes. Uno de los objetivos fundamentales de un anlisis de mercado es descubrir quines sern los clientes potenciales de los productos y servicios propuestos. La labor de clasificar los diferentes tipos de clientes de acuerdo a ciertas caractersticas comunes es tambin muy importante, ya que permite definir diferentes estrategias para cada uno de ellos. Por ejemplo, una empresa que ofrezca la implantacin de sistemas de software libre para empresas se presentar de manera distinta a sus clientes segn ste sea una empresa familiar o una gran corporacin. Hay que tener en cuenta tambin que un mismo producto o servicio puede ofrecerse a clientes a priori diferentes. La flexibilidad e interoperabilidad del software libre favorece esto ltimo. Por otra parte, se debe evaluar la recepcin del producto o servicio por parte de cada tipo de cliente. Siguiendo con el ejemplo anterior de una empresa especializada en la implantacin de sistemas de software libre, una gran empresa que cuente con personal tcnico dedicado puede ser ms reticente a la adopcin del software libre, en parte por el miedo al cambio, mientras que una empresa familiar puede ser ms receptiva. Finalmente, en el caso de que la futura empresa cuente ya con una cartera de clientes, o de que existan clientes que hayan mostrado su inters en sus productos o servicios, es conveniente recoger esto en el estudio de mercado. Anlisisdelacompetenciaydesusproductos. El estudio de mercado debe dar cuenta de los competidores de la futura empresa, as como identificar tanto sus fortalezas y debilidades como las de los productos o servicios que ofrecen. Se debe proporcionar informacin sobre las caractersticas de sus productos y servicios, incluyendo su precio y calidad, as como su cuota de mercado y su estrategia comercial. Es muy importante identificar los lderes 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 futuro, es decir, qu empresas que todava no estn en el mercado podran entrar en l; ni tampoco los de otras regiones geogrficas. En el contexto actual y especialmente en los sectores relacionados con las tecnologas de la informacin y las comunicaciones, como el software libre, la competencia tiende a ser global y muchas empresas pueden ofrecer sus servicios directa o indirectamente en cualquier lugar.
FUOC P08/M2104/00604
127
Anlisisdelasbarrerasdeentrada. Las barreras de entrada son los obstculos que toda empresa se encuentra al entrar en un nuevo mercado. Por ejemplo, la necesidad de una fuerte inversin en el caso de empresas de nueva creacin 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 entrada se pueden favorecer una vez instalados en el mercado, para mantener alejada la competencia.
Influenciadelasadministracionespblicas. El estudio de mercado debe tener en cuenta el modo en que las administraciones pblicas, locales, regionales, nacionales o internacionales pueden afectar al mercado y, en consecuencia, a la viabilidad del plan de empresa. As, las administraciones pueden actuar como reguladoras del mercado, pero tambin 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 inters de mltiples administraciones, como la Junta de Extremadura o el Gobierno de Brasil. La realizacin de un estudio de mercado se debe planificar cuidadosamente y atraviesa diferentes fases, que se resumen en las siguientes: Recogida de informacin general, donde se obtiene un gran volumen de datos sobre el mercado objeto de estudio. Anlisis de la informacin obtenida. Bsqueda selectiva de informacin, donde se obtiene la informacin ausente y necesaria para completar el estudio de mercado, que se habr identificado tras el anlisis previo. Para llevar a cabo la elaboracin de un estudio de mercado se necesita una gran cantidad de informacin, que no siempre es de fcil acceso. Existen numerosos organismos y fuentes de informacin, tanto generales como especializadas en ciertas regiones o sectores: administraciones e institutos de estadstica nacionales, administraciones regionales y locales, organismos privados como las cmaras de comercio o las asociaciones de empresas y revistas y publicaciones especializadas. Un buen estudio de mercado debe concluir con un anlisis estratgico53 que relacione los resultados del propio estudio con la descripcin del negocio y los recursos previstos y que muestre el potencial del plan de empresa.
FUOC P08/M2104/00604 (53)
128
A su vez, este anlisis puede apoyarse en la utilizacin de herramientas estratgicas como el anlisis 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 definicin de las estategias comerciales que permitan alcanzar el volumen de facturacin previsto en el anlisis econmico-financiero, que se ver en detalle en el apartado siguiente.
Por tanto, el plan de marketing detalla las acciones a llevar a cabo para explotar 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: Estrategiacomercialglobal. La estrategia global debe definir de qu manera la parte comercial se integra en el proyecto empresarial. Se debe explicar cmo se van a identificar los clientes y cmo se contactar con ellos, cules son las motivaciones de los clientes al interesarse o decidirse por los productos o servicios ofrecidos y, en consecuencia, las caractersticas de los productos o servicios que se van a destacar para generar ventas, por ejemplo el precio, la calidad, la garanta y el soporte tcnico, etc. El caso del software libre es bastante ilustrativo, ya que el principal reclamo para los potenciales clientes es la reduccin de costes, y no tanto la calidad, que a menudo es superior a la del software propietario. En cambio, el cliente suele identificar los precios elevados del software propietario con una calidad superior, y el software libre, que resulta ms econmico, 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 superior54 del software libre. Estrategiadeventas: define cules 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 cualquier caso, se deben justificar adecuadamente las decisiones, apoyndose en los resultados del estudio de mercado. Estrategiadeprecios: determina en primer lugar los precios con los que se van a comercializar los productos y servicios ofrecidos, comparndolos, si es posible, con los de los competidores, con una estimacin del margen bruto de beneficios y una evaluacin para determinar si este margen es suficiente para soportar toda la actividad empresarial55.
(55) (54)
Por ejemplo, poniendo en primer plano la interoperabilidad y la flexibilidad y la constante revisin y mejoras a las que est sometido el software libre.
Igualmente, es recomendable comparar los mrgenes propios con los de la competencia, en el caso de que se disponga de tal informacin.
FUOC P08/M2104/00604
129
Es muy importante justificar la poltica de precios, sobre todo en comparacin con la de los competidores. En el caso de que el precio de los productos o servicios ofertados sea superior a los de la competencia, se debe explicar en trminos de novedad y calidad, prestaciones y garantas superiores. En el caso de que el precio sea inferior, se debe justificar cmo se mantiene la rentabilidad, por ejemplo gracias a una mayor eficiencia y menores costes de produccin. 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 ms elevado, a pesar de reducir en parte las ventas, puede acarrear mayores beneficios. Polticadeventas: recoge la composicin, forma de contratacin y perfil del equipo comercial o de ventas, incluyendo comerciales y representantes, en el momento de puesta en marcha de la empresa y su evolucin a medio y largo plazo. Esto incluye la poltica de mrgenes comerciales, las medidas de promocin que se van a ofrecer a representantes, comerciales y tambin distribuidores autorizados. Forman tambin parte de la poltica de ventas: la estimacin de las ventas de cada comecial y representante, los incentivos, los perodos de cobro acordados a los clientes, las promociones especiales como descuentos, anticipos, rappels, etc. Promocinypublicidad: debe describir las medidas que se van a poner en prctica para atraer la atencin de clientes potenciales hacia los productos o servicios ofrecidos. Estas medidas incluyen pasar por buzoneos electrnicos, participacin en ferias y eventos comerciales, publicidad en sitios web, etc. Finalmente se debe cuantificar el coste de la promocin y su retorno, en consultas de clientes y ventas cerradas. Servicioposventaygarantas: debe describir el servicio posventa y las garantas que se ofrecen a los productos o servicios ofrecidos, cuando sea aplicable. Es decir, qu tipo de servicio y garanta se ofrece, su duracin temporal, su precio en el caso de que sea optativa y sus costes para la empresa. En el caso del software libre, una parte del servicio posventa est proporcionado 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 aadido. Hay que tener en cuenta que la inmensa mayora de los clientes desean que el servicio posventa est incluido y garantizado en las condiciones de la venta.
FUOC P08/M2104/00604
130
Por ltimo, se debe valorar tambin la importancia del servicio posventa y de las garantas ofrecidas en la decisin final del cliente, y comparar el servicio propio con el proporcionado por los competidores. Polticadedistribucin: La poltica de distribucin debe describir los canales de distribucin que se van a utilizar y las polticas de descuentos, comisiones y mrgenes 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 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 promocin. Por otra parte, como se ha comentado anteriormente, los productos y servicios de software libre pueden ofrecerse a menudo sin problemas en el mercado global, por lo que el plan de marketing debe estudiar esta posibilidad y las particularidades que presentara, incluyendo el efecto de las leyes internacionales en la actividad de la empresa, la gestin de los cobros en el extranjero, etc.
56 (56)
Por ejemplo, el programa de asociados del ERP basado en software libre Openbravo, que podis consultar en http:// www.openbravo.com/partners/ join-openbravo/details/.
3.2.8.
Anlisis econmico-finaciero
El anlisis o estudio econmico-financiero es tambin uno de los elementos bsicos de todo plan de empresa, ya que su objetivo es evaluar la viabilidad y el potencial econmico del proyecto empresarial, detectar las necesidades de inversin para su puesta en marcha, identificar los recursos disponibles inicialmente y presentar las distintas posibilidades de financiacin.
Contrariamente a lo que podra parecer, el anlisis econmico-finaciero es una de las partes ms creativas de la elaboracin de un plan de empresa. Los estados finacieros o aspectos fundamentales que debe cubrir el anlisis econmico-finaciero son los siguientes: Estado de la tesorera durante el primer ao desglosada por meses, a fin de reflejar los efectos de la estacionalidad . Anlisis del fondo de maniobra, que permite conocer la liquidez patrimonial de la empresa. Clculo del punto de equilibrio y alternativas en el caso de que el volumen de ventas objetivo no se alcanzara.
57 (57)
Incluso planes de empresa con un fuerte componente tecnolgico, como los basados en software libre, se ven afectados por la estacionalidad de la economa, por ejemplo durante las vacaciones de verano.
FUOC P08/M2104/00604
131
Necesidades y alternativas de financiacin, elegiendo las ms rentables y aportando los elementos que justifiquen la decisin.
Balances anuales a cinco aos vista, con el primer ao desglosado por meses.
Origen y aplicacin de los fondos, que permite pronosticar situaciones de riesgo para la empresa y evaluar la procedencia y utilizacin 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 lquidos en mayor cuanta que las deudas con vencimiento a corto plazo. Podis obtener ms informacin en http://www.innovaceei.com/es/knowledgebase/index.asp?faqsRecid=385&faqRecid=385&show=4460.
Es conveniente realizar un anlisis conjunto de estos estados financieros y obtener unas conclusiones que aporten informacin sobre el proyecto empresarial en su conjunto: la cantidad de capital necesario y cundo ser necesario, y la deuda necesaria y cundo se debe pagar esta deuda, entre otros. Igualmente se debe explicar la rentabilidad esperada de la inversin y cundo se recuperar esa inversin. Como se coment anteriormente, hay que evitar caer en la tentacin de presentar un anlisis econmico-finaciero demasiado optimista para ganarse la confianza de los inversores, ya que tarde o temprano se volver contra la propia empresa y pondr en entredicho su viabilidad y credibilidad. 3.2.9. Forma legal
(58)
Si el objetivo ltimo del plan de empresa es efectivamente la creacin de una nueva empresa , se debe elegir la forma legal con la que sta se va a constituir, su rgimen fiscal y sus socios fundadores. Del mismo modo, se debe recoger el nombre de todos los socios e inversores y su participacin en la nueva sociedad. Es conveniente detallar paso a paso todos los trmites necesarios para constituir la nueva empresa, as como su coste y el tiempo necesario para su ejecucin. Se debe tambin especificar si se va a recurrir a servicios de asesora externa especializada y su coste.
58
En el caso de que se tratara de un plan de negocio para una empresa ya constituida, este apartado describira la naturaleza jurdica de sta y las posibles modificaciones que la implementacin del plan de negocio podra llevar consigo.
FUOC P08/M2104/00604
132
3.2.10. Gestin de riesgos Todo proyecto empresarial, ya se trate de la creacin de una nueva empresa o de una nueva lnea de negocio, implica numerosos riesgos que en ocasiones son ineludibles. Por ello, el plan de empresa debe incluir una descripcin completa de los riesgos y de sus consecuencias. Los riesgos pueden clasificarse segn sean internos, con origen en la propia empresa, o externos, y segn al rea funcional que afecten: tcnica, comercial, etc. Por ejemplo, riesgos internos pueden ser la existencia de retrasos en la produccin o falta de personal cualificado, mientras que riesgos externos puede ser una nueva regulacin del mercado, que reduzca en parte la rentabilidad o la aparicin de nuevas tecnologias que dejen obsoletos los productos o servicios ofrecidos. Para cada riesgo se debe definir un plan de contingencia, lo que incluye una serie de acciones de prevencin , es decir, para evitar que el riesgo llegue a realizarse, y una serie de acciones de mitigacin o remedio60, qa adoptar en el caso de que el riesgo se realice. Hay que tener en cuenta que algunos riesgos pueden provocar efectos negativos, pero tambin positivos. Por ejemplo, cambios en el marco legal o poltico que pueden afectar al modelo de negocio, pero al mismo tiempo dar lugar a nuevas oportunidades de negocio. La correcta identificacin y evaluacin de los riesgos en un proyecto empresarial y la preparacin de planes de contingencia adecuados, antes que denotar debilidades del proyecto, destacan las habilidades de gestin y de previsin de los promotores y aumentan su credibilidad. 3.2.11. Resumen y evaluacin
59 (59)
Ampliando informacin En el apartado "Gestin de riesgos" de la primera unidad podris encontrar una introduccin general a este tema.
Por ejemplo, para prevenir la aparicin de nuevas tecnologas que pudieran dejar obsoletos los productos o servicios previstos en el plan de empresa se debera poner en prctica una vigilancia tecnolgica activa y, eventualmente, colaborar con empresas u organizaciones que trabajen en la misma rea.
(60)
Por ejemplo, se podran asignar recursos humanos y materiales provenientes de otros departamentos a fin de recuperar el retraso en la produccin.
El ltimo apartado del plan de empresa debe resumir los puntos fuertes y dbiles 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 argumentos a favor del proyecto empresarial y en los que creen sus promotores.
FUOC P08/M2104/00604
133
Sin embargo, puede darse la posibilidad de que tras la elaboracin 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 identificacin de las mejores oportunidades de negocio. 3.2.12. Plan de empresa y software libre La elaboracin de un plan de empresa basado en software libre no presenta grandes diferencias respecto a los planes de empresa de otros sectores y algunas 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, tcnicos, banqueros. Por ello se debe emplear un lenguaje comprensible por todos ellos y evitar la utilizacin de un vocabulario demasiado tcnico. Cuando la utilizacin de estos trminos 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 atencin a explicar las particularidades del software libre, haciendo hincapi en las diferencias respecto al software propietario 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 empresa. Por otra parte, si bien el software libre comienza a tener un papel cada vez ms relevante en los medios y en la sociedad gracias al compromiso de la comunidad de software libre, de empresas y de administraciones pblicas, su naturaleza y sus implicaciones econmicas no son tan conocidas. De nuevo, hay que prestar mucho cuidado a explicar correctamente los modelos de negocio basados en software libre y estar preparado para responder e incluso anticipar las preguntas ms frecuentes. Por ejemplo, cmo se puede invertir y ganar dinero en algo que cualquiera puede copiar? 3.3. Produccin 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 repercusin en la comunidad y slo los muy exitosos llegan a los medios no especializados.
FUOC P08/M2104/00604
134
Sin embargo, antes de abordar la produccin de software libre hay que recordar que la inmensa mayora 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 atencin 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 ingeniera. 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 tambin otras fortalezas y debilidades que conviene conocer. Por el carcter aparentemente no profesional de muchos proyectos de desarrollo de software libre puede parecer que la ejecucin de stos, respecto a la de los proyectos de desarrollo de software tradicionales, sea ms sencilla. Nada ms 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 prcticas que faciliten su xito. Estas prcticas se corresponden con las principales reas y elementos necesarios para poner en marcha y ejecutar un proyecto de software libre, que son las siguientes: Creacin y presentacin del proyecto Infraestructura necesaria Organizacin de la comunidad Desarrollo Releasing y packaging Eleccin 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 iniciadora del proyecto, o bien, en la mayora de los casos, unirse a un proyecto ya existente. Esta ltima opcin es con frecuencia la ms 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 organizacin interesada en dirigir su desarrollo.
FUOC P08/M2104/00604
135
3.3.1.
Creacin y presentacin 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 algn proyecto que realice al menos en parte lo que se pretende. Si hay un proyecto similar de software libre al que se puede contribuir, o que se puede reaprovechar para poner en marcha el nuevo proyecto, es conveniente ponerse en contacto con sus responsables para explorar las posibilidades de colaboracin y sus planes futuros.
Buscadores genricos Los buscadores genricos son la primera etapa para descubrir proyectos existentes, as como los sitios de noticias, los directorios y las forjas pblicas 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 aplicacin, y debe ser fcil de recordar. Para bien o para mal, el ingls es la lengua oficial de facto en Internet. Por ello, si el proyecto busca tener un impacto global, y as debera ser en la mayora de los casos, es conveniente que el nombre tenga cierto significado en ingls, o bien que sea neutro61. Por otra parte, se debe prestar atencin a los aspectos legales, de manera que el nombre no entre en conflicto con marcas registradas y que los potenciales dominios de alto nivel62 en Internet asociados estn disponibles. De la misma manera que se ha visto en el apartado dedicado a la creacin de un plan de empresa, todo proyecto debera contar con una definicin clara de su misin, que atraiga la atencin de usuarios y desarrolladores y les permita decidir si estn interesados en el proyecto, o no. Junto a la misin, es igualmente importante identificar inequvocamente el proyecto como software libre, lo cual implica hacer una referencia clara a software libre (free software) o software de cdigo abierto (open-source software). Otros elementos importantes a la hora de presentar un proyecto de software libre son: Listadefuncionalidadesprevistas63yrequisitosactuales. Redactada de una manera sencilla, es decir, sin tecnicismos. Es, en cierto modo, un resumen detallado de lo que hace el software, que permita a los usuarios saber fcilmente si se trata de las funcionalidades que buscan.
(63) (61)
Es decir, que sea un nombre comn a varias lenguas, como Apache, o que no se asocie a otra lengua mayoritaria, como por ejemplo Ubuntu.
(62)
Es decir, los dominios .com, .net y .org.
Se pueden indicar con una mencin "en progreso" o "en desarrollo", idealmente con la fecha o la versin en que estarn disponibles.
FUOC P08/M2104/00604
136
De igual modo, los requisitos deben ser fciles de entender, de manera que el usuario sepa si puede instalar y utilizar la aplicacin en su sistema. Estadodedesarrollo. En la comunidad de software libre los usuarios suelen estar muy interesados en saber cmo avanza el desarrollo del proyecto, 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 estarn disponibles en futuras releases, etc. Descargasdisponibles. El cdigo fuente debe poder descargarse siempre en formatos estndar, de una manera sencilla, que no suponga ninguna complicacin para el usuario64. El proceso de instalacin tambin debe ser sencillo y, sobre todo, de acuerdo a los estndares desde el principio del proyecto. Igualmente, en un primer momento no es necesario facilitar paquetes binarios o ejecutables, a menos que el proceso de compilacin sea muy complejo. Repositorio de desarrollo. Los potenciales desarrolladores, al contrario que los usuarios, estn ms interesados en acceder al repositorio de trabajo, donde se puede seguir la evolucin del proyecto da a da y participar en ella, ya sea aadiendo nuevas funcionalidades o corrigiendo errores. Para ello es conveniente que todos puedan acceder a la lectura del repositorio, mediante un acceso annimo. Seguimientodeerrores. Al igual que el repositorio, la base de datos de seguimiento de errores
65 (65) (64)
Es conveniente, por ejemplo, evitar procesos de registro de usuarios para acceder a la seccin de descargas.
debe estar tambin abierta a todos. Paradjica-
Con frecuencia se hace referencia a los trminos bug tracker o bug database en ingls.
mente, un proyecto es mejor cuantos ms errores contiene su base datos, ya que esto implica un mayor nmero usuarios y una mayor participacin de los usuarios en el proyecto. Al inicio del proyecto, el nmero de errores ser muy bajo. Una buena prctica es registrar en la base de datos los errores resueltos internamente por el equipo que pone en marcha el proyecto. Canalesdecomunicacin. Uno de los objetivos de todo proyecto de software libre es crear una comunidad alrededor de l y, para que dicha comunidad se organice, es necesario facilitar los canales de comunicacin adecuados. Esto incluye listas de correo, canales de IRC, foros, etc. En una primera fase del proyecto es conveniente no diversificar ni especializar en exceso los canales de comunicacin. Un nico foro o lista de distribucin para usuarios y desarrolladores puede ser suficiente y favorecer las interacciones entre ellos. Documentacinparausuariosydesarrolladores. La documentacin es esencial en todo proyecto de software libre, tanto para los usuarios como para los desarrolladores.
FUOC P08/M2104/00604
137
Una buena documentacin para el usuario debe explicar a ste cmo instalar el software y cmo utilizar sus funciones. Se le puede facilitar tambin un pequeo tutorial, que le ensee a realizar las tareas ms frecuentes paso a paso. Un excelente complemento de la documentacin es el mantenimiento de una seccin de preguntas frecuentes o FAQ. La documentacin para desarrolladores debe incluir la informacin de contacto de los principales desarrolladores del proyecto, las instrucciones para enviar informes de errores y parches, as como una presentacin sobre la organizacin del desarrollo y la toma de decisiones entre los desarrolladores. Todos estos elementos se vern en detalle en los apartados siguientes. Para concluir este apartado cabe destacar que la apariencia es decir, cmo 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 atencin a esta tarea de comunicacin y relaciones pblicas, la cual, sin embargo, es un elemento indispensable en prcticamente todos los proyectos de software libre de xito. Para ello hay que definir claramente cuales son los objetivos del nuevo software, que normalmente se pueden resumir en: Definirclaramentequhaceelsoftware: sus funcionalidades principales, el estado actual de desarrollo y los planes de futuro, adems de su posicionamiento respecto a las soluciones y los proyectos ya existentes. Daraconocerelsoftware: hacerlo llegar a la comunidad o al mercado de usuarios y desarrolladores potencialmente interesados. Potenciarelusodelsoftware: que los usuarios y los desarrolladores potenciales sepan utilizar el nuevo software y lo adopten frente a las soluciones alternativas. Involucrarnuevosdesarrolladoresenelproyecto: que stos contribuyan al desarrollo del proyecto mediante la implementacin de nuevas funcionalidades y que aporten sus puntos de vista sobre la direccin que debera tomar el proyecto en el futuro. Los dos ltimos objetivos, conseguir muchos usuarios y muchos desarrolladores, son a menudo los ms importantes. Sin embargo, es necesario poner en prctica una estrategia para los usuarios y otra diferente para los desarrolladores, los cuales, aun perteneciendo a la misma comunidad de software libre, representan audiencias muy distintas.
FUOC P08/M2104/00604
138
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 software, ni tampoco adentrar a los desarrolladores en detalles tcnicos sin antes dar una visin adecuada de la arquitectura. Finalmente, este mensaje debe ser fcilmente 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 documentacin, entre otros. 3.3.2. Infraestructura
Cualquier proyecto de software libre necesita una serie de herramientas que permitan gestionar la informacin que se genera en el da a da del proyecto, desde el cdigo 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: Sitioweb Proporciona una fuente centralizada de informacin sobre el proyecto y da acceso a otras herramientas de gestin especializadas. Listasdecorreo Es uno de los canales de comunicacin utilizados con ms frecuencia en los proyectos de software libre. Los intercambios de mensajes suelen quedar archivados y se utilizan como referencia y base de conocimiento del proyecto. Sistemadecontroldeversiones Permite que los desarrolladores controlen la creacin y la gestin de cdigo, volviendo a versiones anteriores y uniendo diferentes versiones. Gracias al sistema de control de versiones, cualquiera puede visualizar el estado actual del cdigo, as como su evolucin en el tiempo. Sistemadeseguimientodeerrores Permite que los desarrolladores realicen un seguimiento de las funcionalidades y los errores en los que est trabajando cada uno, se coordinen entre ellos y planifiquen las prximas releases. Si bien el seguimiento de errores es su funcin 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
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. Chatocanaldeconversacin Proporciona un canal de comunicacin donde resolver dudas y problemas rpidamente. Las conversaciones no se suelen archivar, por lo que es aconsejable que las discusiones ms complejas tengan lugar en listas de correo. Cada una de estas herramientas responde a unas necesidades concretas, principalmente de comunicacin y de gestin de la informacin. La experiencia y las caractersticas de la comunidad de usuarios y desarrolladores alrededor del proyecto van a dictar la configuracin y el uso de estas herramientas. No obstante, vale la pena comentar algunos aspectos que pueden resultar de utilidad para la mayora 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 atencin a su gestin y uso. Es prcticamente obligatorio disponer de un sistema gestor de listas de distribucin, cuya configuracin y mantenimiento pueden resultar complicados en un principio. Las funcionalidades y las opciones principales de un sistema gestor de listas de distribucin son las siguientes: Suscripcin mediante correo electrnico y mediante una interfaz web Suscripcin en modo digest o normal66 Moderacin Interfaz de administracin Configuracin de las cabeceras de los mensajes Gestin y consulta de archivos
Recursos web Entre los sistemas ms populares estn Mailman (http://www.list.org), Smartlist (http:// www.procmail.org), Ecartis (http://www.ecartisorg), Listproc (http:// listproc.sourceforge.net) o Ezmlm (http://cr.yp.to/ exmlm.html).
(66)
En el modo digest se recibe una compilacin de todos los mensajes peridicamente, normalmente cada mes o cada semana, mientras que en el modo normal los mensajes se reciben inmediatamente.
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 cdigo fuente o modificaciones 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
FUOC P08/M2104/00604
140
desarrollador dispone de una copia local de esa copia remota, sobre la que trabaja. Puntualmente, cada desarrollador enva sus modificaciones a la copia remota, compartindolas 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 dems 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 debera limitar a los archivos de cdigo fuente. La utilizacin de un sistema de control de versiones puede resultar muy prctica para editar y compartir documentacin o informes tcnicos y, en general, para cualquier documento que haya sido creado y mantenido en colaboracin. Como se ha comentado anteriormente, el sistema de seguimiento de errores permite realizar muchas otras funciones, adems de la que indica su nombre. Esto incluye el seguimiento de cualquier tipo de tarea, como la implementacin de funcionalidades nuevas, la preparacin de releases o el soporte a los usuarios. El ciclo de vida de un error suele ser el siguiente: Notificacindelerror: Todo error incluye al menos un resumen y una descripcin inicial que contienen, a ser posible, los elementos necesarios para reproducir el error. La mayora de sistemas de seguimiento de errores permite configurar campos especficos. No hay que olvidar que los errores pueden venir tanto de la comunidad de usuarios como de la de desarrolladores. 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 descripcin del error y, eventualmente, pedir ms informacin al usuario o al desarrollador que lo ha notificado. Reproduccindelerror: Siguiendo las indicaciones de la descripcin del error, alguien consigue reproducirlo, por lo que ste queda validado. Es decir, se puede decir que el error es autntico. Diagnsticodelerror: Durante las fases anteriores puede ocurrir que un desarrollador se haga responsable de la resolucin del error, o bien que
FUOC P08/M2104/00604
141
alguien con autoridad dentro del proyecto lo asigne al desarrollador ms adecuado. Asignacindelerror: durant les fases anteriors pot passar que un desenvolupador es faci responsable de la resoluci de l'error, o b que alg amb autoritat dins del projecte l'assigni al desenvolupador ms adequat. Es esencial notificar esto en la base de datos, a fin de evitar que dos desarrolladores estn trabajando en la resolucin del mismo error sin saberlo. Es posible notificar igualmente la fecha esperada de resolucin, o la release en la que el error se habr solucionado. Resolucindelerror: Una vez el desarrollador resuelve el error, lo marca como cerrado o resuelto. A veces los errores se resuelven rpidamente, 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 solucin, siempre es conveniente registrar el error y comunicrselo adecuadamente al usuario. Otra situacin 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 notificacin, lo que permiten concentrar esfuerzos y disponer de toda la informacin en el mismo lugar. Finalmente, puede ocurrir que un error considerado como resuelto no lo est en realidad, generalmente porque el patrn de reproduccin seguido no coincide con el proporcionado por el usuario que ha notificado el error. En este caso, el usuario puede reabrir el error, aportando siempre toda la informacin necesaria. Existen numerosas forjas pblicas que ofrecen estas y otras herramientas, listas para ser utilizadas en los proyectos de software libre. Estas plataformas ofrecen una serie de ventajas y desventajas.
Recursos web Entre las forjas pblicas ms populares estn SourceForge (http://www.sourceforge.net), Savannah (http://savannag.gnu.org o BerliOS.de (http://www.berlios.de). Adems, algunas organizaciones ofrecen alojamiento a proyectos dentro de su rea de inters, 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 mantener un servidor de alta disponibilidad en marcha. Por otra parte, las herramientas proporcionadas por estas forjas estn ya configuradas y normalmente son muy sencillas de utilizar. Evidentemente, la desventaja principal es que la flexibilidad y las posibilidades de configuracin de las herramientas ofrecidas son limitadas.
FUOC P08/M2104/00604
142
As, al comenzar el proyecto puede ser recomendable albergarlo en una forja pblica, 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 pblica para los aspectos ligados al desarrollo del cdigo puede ser, aunque no una solucin ptima, s un buen compromiso. 3.3.3. Organizacin de la comunidad
Una de las mayores diferencias entre los proyectos de software libre y los proyectos de software propietario es el modo de organizarse de la comunidad de desarrolladores.
En un proyecto de software propietario, la organizacin corresponde normalmente a la organizacin jerrquica del equipo o el departamento que, dentro de una empresa, lleva a cabo a cabo el desarrollo. Aunque en un proyecto de software libre tambin se aprecia a veces cierta jerarqua, parcialmente basada en los mritos de cada desarrollador, la organizacin de la comunidad de desarrolladores es ms flexible pero tambin ms fuerte.
Paradjicamente, uno de los motivos que hacen que la comunidad de desarrolladores trabaje y se mantenga unida es la posibilidad de crear un nuevo proyecto independiente67 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 escisin hace que la comunidad busque un consenso ms o menos democrtico en las grandes decisiones del proyecto. En general, existen dos formas de organizacin de las comunidades de software libre, si bien la mayora de los proyectos acaban adoptando una posicin intermedia entre ambas. Estas dos formas son las siguientes: Organizacinbasadaenun"dictadorbenevolente". El dictador benevolente es una figura con autoridad para tomar decisiones definitivas, de importancia para la vida del proyecto. Sin embargo, a menudo el dictador benevolente no toma las decisiones directamente, sino que suele actuar ms bien de rbitro en las discusiones, tratando de compatibilizar los puntos de vista de los desarrolladores e identificar las aportaciones ms valiosas. Otra forma de actuacin del dictador benevolente es delegar en expertos que puedan ocuparse de las decisiones o discusiones en
(67)
En ingls, forkability, es decir la posibilidad de realizar un fork.
FUOC P08/M2104/00604
143
marcha. El dictador benevolente suele ser un desarrollador con suficiente experiencia en el proyecto y en las tecnologas relacionadas, pero que no es necesario que sea el ms experto. Basta con que sea capaz de entender el proyecto en su totalidad y reconocer las contribuciones de mayor calidad. Organizacinbasadaenelconsenso. Por consenso se entiende los acuerdos que toda la comunidad acepta ms o menos tcitamente, es decir, cuando nadie se opone a las decisiones ni a la direccin 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 votacin. La mayora de discusiones en la vida de un proyecto suele ser de naturaleza tcnica, por lo que el consenso se produce cuando todo el mundo esta de acuerdo en, por ejemplo, el diseo o la implementacin de una funcionalidad o en la manera de resolver un error. En estos casos, adems, un miembro suele hacer un resumen de la discusin al final de sta. En general todas las comunidades, y especialmente las basadas en el consenso, tienen un excelente apoyo en el sistema de control de versiones, el cual permite volver atrs y deshacer cualquier decisin que se revele equivocada. Los proyectos suelen comenzar con una organizacin basada en un dictador benevolente y, a medida que la comunidad crece, se mueven hacia una organizacin ms basada en el consenso. Esto suele ocurrir en ciertos momentos de la vida del proyecto, como por ejemplo cuando el dictador benevolente abandona su posicin y su autoridad se diluye en la comunidad, especialmente entre los miembros ms respetados de sta. Al cabo de un tiempo, las convenciones y los acuerdos tomados por una comunidad mediante consenso pueden ser muy grandes, por lo que es conveniente recoger los elementos principales en un documento que sirva de gua y referencia en el futuro. ste puede incluir tanto la forma de gobierno de la comunidad, como las convenciones y las recomendaciones para los desarrolladores. Finalmente cabe preguntarse cul es el papel de las empresas en las comunidades 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 desarrolladores. Por otra parte, puede darse el caso de una empresa que se una a un proyecto 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 cul va a ser su participacin en la comunidad.
Recursos web Podis consultar las guas del proyecto Subversion (http:/ /svn.collab.net/repos/svn/ trunk/HACKING) o de la Fundacin Apache (http:// www.apache.org/foundation/ how-it-works.html y http:// www.apache.org/foundation/ voting.html).
FUOC P08/M2104/00604
144
Las posibilidades son muy variadas. Por ejemplo, la empresa puede buscar una posicin de liderazgo en la comunidad y dirigir el proyecto o, sencillamente, tener voz en las discusiones, participar activamente en la implementacin 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 situacin, el modelo de organizacin basado en el dictador benevolente parece el ms adecuado, al menos al principio, pero es necesario definir las reglas de participacin de la comunidad. El reto es, por una parte, conseguir 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 solucin, si bien difcil, pasa por ofrecer ventajas o algn tipo de valor aadido a los usuarios y a los desarrolladores que participen en la comunidad. Una buena prctica consiste en que el equipo de desarrollo de la empresa trabaje complemente integrado en la comunidad y siguiendo la metodologa de desarrollo del proyecto de software libre. Esto implica que la participacin 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 software libre, no desde el punto de vista tcnico, que depender de la naturaleza de cada proyecto, sino desde el punto de vista de la gestin del proyecto y la coordinacin 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 organizacin centralizada. Por ejemplo, cuando se aproxima la fecha de una nueva release, una empresa puede dedicar un nmero arbitrario de recursos a su preparacin. En cambio, los desarrolladores voluntarios que forman la comunidad no son tan fciles 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
De este modo, la distribucin 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 aproximacin no deja de ser en parte ideal y, en la mayora 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 explcitamente por los iniciadores del proyecto o el dictador benevolente o, implcitamente, por los miembros con ms experiencia y ascendencia sobre la comunidad. Algunas de las tareas principales de coordinacin, 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 tarea 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 travs de un canal de comunicacin visible para toda la comunidad y dando siempre la opcin de declinar la oferta. En este caso, el coordinador debe conocer las habilidades y los intereses de los miembros de la comunidad y, en funcin de ello, dirigir sus demandas. Por ejemplo, no tiene sentido pedir algo a alguien que no tiene la capacidad necesaria para llevarlo a cabo, ni tampoco a alguien que ya realiza numerosas tareas. Realizarcrticasyelogios: la valoracin adecuada de las contribuciones de cada uno de los desarrolladores del proyecto tiene un papel muy importante en la creacin 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 repercusin en la comunidad. Por ello, tanto las crticas como los elogios deben utilizarse cuidadosamente. Hay que recordar que las crticas continuas o injustificadas van a causar seguramente una mala reaccin, al igual que los elogios. Sin embargo, en una discusin tcnica, una crtica detallada puede considerarse en s misma como algo positivo, ya que implica que la persona que la realiza se ha tomado el inters de analizar el diseo o la implementacin objeto de la crtica. Evitarlaterritorialidad: una situacin a evitar es aquella en la que ciertos miembros de la comunidad pretenden apropiarse de una parte ("su parte") del proyecto y no aceptan ninguna crtica o contribucin 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 ningn otro desarrolla-
FUOC P08/M2104/00604
146
dor revisa el cdigo realizado, con la consiguiente prdida de calidad y la fragmentacin de la comunidad. Automatizartareas: en general, la mayora de desarrolladores trabaja en una parte del cdigo y desconoce qu es lo que hacen los dems. Por tanto, es responsabilidad de los coordinadores tener una visin global del proyecto y saber a qu se dedica cada miembro. As resulta fcil identificar una serie de tareas inherentes al desarrollo del cdigo que todos los desarrolladores llevan a cabo y que a menudo puede ser conveniente automatizar y centralizar. El ejemplo ms evidente de esto es la automatizacin de tests68, que permite que los desarrolladores realicen cambios y experimenten con partes del cdigo con las que no estn familiarizados. Trataradecuadamentealosusuarios: la existencia de una comunidad de usuarios activa y que proporcione informacin valiosa a los desarrolladores es esencial para el xito de todo proyecto de software libre. Sin embargo, a menudo los desarrolladores y los usuarios hablan, por as decirlo, lenguajes diferentes. Muchos usuarios no estn 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 mayora de usuarios no se dirige nunca a la comunidad de desarrolladores, hay que tratar con especial atencin a los que s lo hacen. Por ejemplo, cuando un usuario indica que una parte de la documentacin est incompleta se le puede proponer que la complete l mismo y, cuando notifique un error, preguntarle si podra intentar resolverlo. Y, por supuesto, agradecer siempre su contribucin, sea la que sea. Compartirtareasdegestin: adems del desarrollo del cdigo, todo proyecto lleva aparejadas una serie de tareas de gestin que, conforme el proyecto crece, se vuelven ms complejas. Los coordinadores o el equipo que inici el proyecto suelen encargarse de ellas, pero es una buena prctica compartirlas con otros miembros del proyecto, tal y como se ha visto en el punto dedicado a la delegacin. Entre estas tareas destacan: Gestindeparches. Controlar qu parches se han recibido y analizarlos para aceptarlos o, en la mayora de los casos, identificar sus problemas y notificarlos al autor del parche. Gestindetraducciones. Coordinar la traduccin de la documentacin y del software. Gestindedocumentacin. Mantener la documentacin al da e integrar las modificaciones conforme stas van apareciendo, as como la seccin de preguntas frecuentes o FAQ.
(68)
En particular, la creacin de un paquete de pruebas, un programa que ejecuta el software del proyecto a fin de reproducir todos los errores conocidos y corregidos anteriormente. Esto permite que los desarrolladores se aseguren que no provocan de nuevo errores antiguos ya resueltos.
FUOC P08/M2104/00604
147
Gestindeerrores. Gestionar la base de datos de errores, lo que incluye, entre otras funciones, asegurar su integridad y evitar la existencia de errores duplicados.
Gestionar permisos. una de las tareas de gestin que merece mencin aparte es la gestin de los permisos o, en otras palabras, decidir quin tiene permiso para realizar commits y por tanto puede integrar su cdigo en la copia remota del repositorio. Igualmente, la concesin de permisos implica tambin su posible revocacin. Los desarrolladores que no tienen permiso para realizar commits pueden, por supuesto, contribuir al desarrollo del proyecto, realizando parches que resuelvan errores o aadan nuevas funcionalidades y que sern analizados por los desarrolladores del proyecto y finalmente incorporados. De hecho, el mecanismo ms habitual de obtencin del permiso para realizar commits es que un desarrollador contribuya con parches al proyecto, hasta que el equipo de desarrolladores considere que sus aportaciones y su conocimiento del proyecto son suficientemente valiosos. Para motivar la participacin de nuevos desarrolladores, es conveniente que el procedimiento de obtencin del permiso para realizar commits sea pblico y lo ms transparente posible, as como su posible revocacin.
3.3.5.
Releasing y packaging
La preparacin de las releases y el empaquetado o packaging son, junto con el desarrollo del cdigo, unas de las tareas ms 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 sido solucionados y muy probablemente haya otros nuevos. Adems, es posible que haya funcionalidades y opciones de configuracin nuevas. Incluso puede que aparezcan incompatibilidades entre la nueva versin 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 cmo se va a identificar cada una de las releases. Para ello hay un buen nmero de convenciones ms o menos creativas, pero lo ms habitual es numerarlas con una serie de dgitos separados por puntos. Por ejemplo: Release 3.4.1
FUOC P08/M2104/00604
148
Release 3.4.2 Release 3.5 Release 4.0
El significado de los dgitos puede variar. Los cambios en el tercer dgito suelen implicar soluciones a errores o pequeas mejoras en algunas funcionalidades. Los cambios en el segundo dgito suelen significar la introduccin de nuevas funcionalidades. Finalmente, los cambios en el primer dgito 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 numeracin de las releases en el sitio web del proyecto. Adems, algunas releases se suelen identificar con la palabra alpha o beta, segn su estado de desarrollo. Por ejemplo: Release 3.4.1 (alpha 1) Release 3.4.1 (alpha 2) Release 3.4.1 (beta)
Pgina web Podis consultar el esquema de versiones del proyecto APR (http://apr.apache.org/ versioning.html).
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 an un buen nmero de errores. Los usuarios que instalan y ejecutan una versin alpha suelen hacerlo para evaluar el software y notificar los errores al equipo de desarrolladores. Una versin beta, en cambio, est mucho ms depurada y si casi no contiene errores se convertir en la versin oficial: es lo que se llama una versin candidata. Para los desarrolladores, un proyecto de software libre est continuamente en proceso de release, y utilizan siempre la ltima versin disponible en el repositorio para su desarrollo, por lo que puede ser difcil capturar el momento exacto de la release. La mejor prctica para realizar esto es mantener una rama o branch en el repositorio que contenga el cdigo que se introducir en la prxima release, independientemente del tronco o trunk. De este modo, adems, los desarrolladores que no estn involucrados en la preparacin de la release pueden seguir trabajando en el proyecto. En consecuencia, una de las partes ms importantes del proceso de preparacin de una release es su estabilizacin, es decir, decidir qu cambios y funcionalidades van a integrarse en la rama de la prxima release. Aqu, el mecanismo de toma de decisiones de la comunidad de software libre debe ponerse de nuevo en marcha y otra vez hay dos alternativas principales:
FUOC P08/M2104/00604
149
Designar un propietario de la release, o release owner, que decide qu cambios 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 votacin. Una solucin intermedia es fijar un nmero mnimo de desarrolladores que debe votar para que un determinado cambio se incluya.
Adems, 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 cdigo fuente, adecuadamente empaquetado y comprimido en un formato estndar . El nombre del paquete suele estar formado por el nombre del paquete, el nmero de versin y el sufijo apropiado segn el formato. Por ejemplo: miproyecto-3.4.1.tar.gz miproyecto-3.4.2.zip
69 (69)
En sistemas GNU/Linux, la convencin es utilizar el formato TAR, comprimido por compress, gzip, bzip o bzip2. En sistemas Windows suele utilizarse el formato ZIP.
Entre la informacin que debe acompaar a toda nueva release se incluye la licencia bajo la cual se distribuye, las instrucciones de instalacin y configuracin y los cambios y las novedades respecto a la ltima release70. Esta informacin se recoge en una serie de archivos de nmero ms o menos estndar: LICENSE o COPYNG, README o INSTALL, y CHANGES. Finalmente, el usuario debe realizar la compilacin del cdigo fuente y su instalacin en el sistema, que debe realizarse siempre de manera estndar si se desea que el software llegue al mayor nmero de usuarios posible. Otra posibilidad, empleada sobre todo con software ya maduro, es la distribucin de paquetes binarios, ya sea como ejecutables o instalables, que en cualquier caso evitan que el usuario deba realizar el proceso de compilacin manualmente70. Desde el punto de vista de la empresa de software libre, la poltica de releases es una de las herramientas ms importantes para atraer a los usuarios potenciales del software. Una planificacin adecuada de las releases debe dar respuesta puntualmente a las necesidades de los usuarios, ya sea en nuevas funcionalidades como en la correccin de errores, por lo que debe encontrarse el ritmo adecuado de publicacin de las nuevas releases. Por ejemplo, publicar nuevas releases con demasiada frecuencia puede saturar al usuario, que probablemente no las instalara todas y, al contrario, dejar pasar demasiado tiempo entre releases podra hacer que el usuario buscara soluciones alternativas. Del mismo modo, es conveniente asegurar la calidad de las nuevas releases, intentando corregir la mayor cantidad de errores antes de su publicacin. 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
del proyecto y de la empresa, que luego puede resultar difcil de enmendar. Por ello, es especialmente importante apoyarse en el carcter abierto y cooperativo del software libre para mejorar su calidad. 3.3.6. Eleccin de licencias
Las diferencias, las ventajas y los inconvenientes de cada una de las licencias de software libre es uno de los temas de discusin ms recurrentes. Sin embargo, lo cierto es que la eleccin de una u otra licencia tiene un papel menor en la adopcin y el xito del proyecto, siempre y cuando sta sea de software libre. La inmensa mayora de los usuarios elige una determinada solucin segn la funcionalidad y la calidad que ofrece, pero no segn su licencia. Lo ms importante es tener claro cules son los objetivos del proyecto y cules son los objetivos de la empresa de software libre respecto al proyecto y, en funcin de ello, elegir la licencia ms adecuada o bien definir una nueva basada en las ya existentes71. As, numerosos proyectos de software libre proporcionan su propia licencia, adaptada a sus necesidades y objetivos72.
(71)
El anexo I proporciona una lista breve de las principales licencias utilizadas en la produccin de software libre.
(72)
Por ejemplo, la licencia OpenBravo (http:// www.openbravo.com/product/legal/license/) o la licencia dual de MySQL (http://www.mysql.com/ about/legal/licensing/).
Las licencias de software libre, las relaciones y las incompatibilidades potenciales 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 reutilizacin de componentes libres bajo licencias restrictivas. Un ejemplo tpico es la licencia GPL, que obliga a que todo software que utilice componentes GPL sea a su vez distribuido bajo licencia GPL. Una buena prctica es la realizacin, desde el inicio del proyecto, de un inventario o mapa del software externo y las licencias utilizadas en el proyecto, que describa en qu partes del cdigo se utilizan.
Ved tambin La asignatura del mster oficial de Software libre, Aspectos legales y de explotacin del software libre, profundiza en estos aspectos.
FUOC P08/M2104/00604
151
Resumen
A pesar de que la tecnologa basada en software libre ha sido probada, se encuentra en produccin y funcionamiento en multitud de escenarios, y que es fcil encontrar en los medios de comunicacin generalistas noticias sobre productos, eventos o personalidades relacionados con el software libre, siguen existiendo un gran nmero de tpicos entorno a su implantacin real y efectiva. Estos tpicos e ideas preconcebidas a menudo juegan en contra de la implantacin de sistemas basados en software libre, ya sea a nivel particular u organizativo. Desde el punto de vista del usuario, se suele decir que el software libre es para expertos en informtica o hackers, o que las aplicaciones basadas en software libre son inestables, no estn 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 prdida de competitividad, o que salvo excepciones, no existen modelos de negocio viables entorno al software libre. En definitiva, la mayora de estas ideas se pueden resumir en la falta de calidad 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 pblicas y grandes organizaciones con el software libre debera ayudar a reconsiderar la validez de estos prejuicios. Por otra parte, numerosos expertos y analistas destacan el potencial del software libre para impulsar el desarrollo ecnomico tanto a nivel local como europeo o mundial. Por ejemplo, segn Gartner "el software libre es un catalizador que va a restructurar la industria, produciendo software de calidad superior a un coste ms bajo". Los materiales de esta asignatura pretenden dar respuesta a algunos de estos tpicos, formando profesionales capaces de llevar a cabo proyectos de implantacin de sistemas de software libre a travs del estudio detallado desde un punto de vista conceptual, metodolgico y prctico de este tipo de proyectos en una variedad de escenarios y situaciones.
FUOC P08/M2104/00604
152
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 ingeniera, por lo que los presentes materiales no pueden ni deben sustituir los conocimientos necesarios que sn propios a estas materias. En este sentido, la mayor parte de los materiales se ha dedicado a estudiar los conceptos, metodologas y herramientas necesarios para llevar a cabo proyectos de desarrollo e implantacin de software libre. Esto justifica el tratamiento generalista de algunos de los contenidos, aproximando progresivamente al lector en las particularidades metodolgicas de los proyectos basados en software libre, tratando de ordenar y estructurar de forma conceptual y funcional las principales etapas e hitos de la implantacin. Adems, se ha presentado cmo la actividad econmica en torno al software libre, ya sea en forma de desarrollo de software, consultora, integracin, implantacin o soporte, puede ser objeto de un modelo de negocio lucrativo, vlido 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 evolucin de las tecnologas y de los proyectos de software libre dejar obsoleta al menos una parte de estos materiales, especialmente aquella que hace referencia a proyectos y soluciones concretas. No obstante, tanto la metodologia presentada como las referencias bibliogrficas aportadas deberan ayudar a encontrar la solucin adecuada para cada proyecto o escenario de implantacin. Por otra parte, se espera que la formalizacin y estructuracin de las metodologas y procedimientos presentados, as como la coleccin de buenas prcticas en proyectos de software libre, supongan una aportacin cualitativa para la comunidad y para el desarrollo y expansin del software libre en general. Finalmente, no se puede finalizar estas lneas sin agradecer a la Fundaci de la Universitat Oberta de Catalunya (http://www.uoc.edu) su apoyo en la elaboracin del presente material didctico. 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 prctica diaria en la implantacin de sistemas basados en software libre.
FUOC P08/M2104/00604
153
Glosario
ciclo de vida de un proyecto m Proceso que engloba, estructura, organiza y coordina todas las etapas y las fases que guan la ejecucin 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 Acrnimo de "debilidades, amenazas, fortalezas y oportunidades" (en ingls, SWOT). El anlisis DAFO es una herramienta de planificacin estratgica que se utiliza para evaluar las debilidades, las amenazas, las fortalezas y las oportunidades relacionadas con un proyecto. estndar abierto m Formato o protocolo que est sujeto a la utilizacin y a la evaluacin pblicas, que no depende de otros formatos o protocolos que no sean abiertos, que no contiene clusulas que limiten su utilizacin, 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 Anlisis 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 econmica, partiendo del entorno general, la competencia y los consumidores. gestin de proyectos f Disciplina que estudia la manera ptima de organizar y administrar los recursos disponibles de forma que se pueda culminar toda tarea requerida en el proyecto dentro del plazo, el tiempo y el coste definidos. implantacin de sistemas f Proceso mediante el cual se instauran una o ms novedades tecnolgicas en una organizacin, como resultado de una actuacin que deriva del plan estratgico de la misma. implantacin directa f Proceso mediante el cual el sistema que debe instaurarse no requiere una gran adaptacin o configuracin 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 estratgico que consiste en la delegacin o la produccin de operaciones o trabajos en un departamento interno de la organizacin, normalmente especializado, en lugar de subcontratarlos a un tercero externo a la organizacin. licencia f Modelo contractual en el cual el autor del producto (o el poseedor de los derechos de autora) 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 bsicos libertad: ejecutar el software con cualquier propsito, estudiar el cdigo fuente y adaptarlo, redistribuir copias del software, mejorar el cdigo fuente y publicar las mejoras. metodologa f Anlisis o estudio sistemtico de los mtodos y los procedimientos que son, han sido o pueden ser aplicados a una determinada disciplina. migracin f Proceso de sustitucin de unas infraestructuras basadas en software propietario por otras con funciones equivalentes basadas en software libre. modelo de negocio m Estrategia empresarial que define, planifica, produce y comercializa uno o ms productos o servicios orientados al lucro de sus productores. outsourcing Modelo estratgico que consiste en la delegacin o la produccin de operaciones o trabajos en una organizacin externa a la organizacin, normalmente especializada, en lugar de delegarlos a un departamento interno de la organizacin. packaging o empaquetamiento m Proceso para automatizar la instalacin, la configuracin y la desinstalacin de los paquetes de software en un ordenador. En concreto, los sistemas GNU/Linux emplean habitualmente miles de paquetes diferentes. plan estratgico de la organizacin m Conjunto de propuestas que definen los objetivos o las tendencias de la organizacin en el futuro. Normalmente se desarrolla con posterioridad en las diferentes reas o departamentos funcionales de la organizacin.
FUOC P08/M2104/00604
154
software libre m Conjunto de programas y aplicaciones informticas cuyas condiciones de explotacin se encuentran bajo una licencia libre. proyecto m Proceso de gestin de recursos organizado, estructurado y planificado para alcanzar un determinado objetivo, normalmente estratgico. releasing o distribucin m Proceso para hacer llegar la versin inicial o la actualizacin de un producto de software a sus usuarios potenciales. repositorio m Un repositorio, depsito o archivo es un lugar centralizado donde se almacena y mantiene informacin digital, habitualmente bases de datos o archivos informticos. En el desarrollo de software libre, los repositorios incorporan un sistema de control de versiones que mantiene el registro de todo el trabajo y los cambios en los archivos (principalmente cdigo fuente) que forman un proyecto y permite que diferentes desarrolladores (potencialmente separados por grandes distancias) colaboren. riesgo m Acontecimiento probable que puede afectar a la marcha del proyecto y, eventualmente, impedir que se alcancen los objetivos a tiempo. servicios del sistema m Conjunto de funciones que se pueden ejecutar, con o sin intervencin del usuario, y que se consideran esenciales para el funcionamiento de la organizacin. sistema m Conjunto de elementos o componentes independientes, fsicos o lgicos, 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 incidencias ocasionadas durante la utilizacin de un programa o aplicacin. versin f Nmero que indica el nivel de desarrollo de un programa o aplicacin.
FUOC P08/M2104/00604
155
Bibliografa
Abella, A.; Snchez, J.; Santos, R., y otros (2003). Libro Blanco del software libre en Espaa. [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 Espaa (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 Espaa (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 Hottest IT Topics and Trends in 2005". [Fecha de consulta: 20 de mayo de 2008]. http:// www.gartner.com/DisplayDocument?doc_cd=125868 Daz, R. M. (2007). El arte de dirigir proyectos (2a. ed.). Madrid: Ra-ma, 1995. Guitrrez, J. D. (2007). Metodologa para el anlisis decisorio de la implantacin de software 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 consulta: 01 de marzo de 2008]. http://www.hecker.org/writings/setting-up-shop.html Kerchmer, K. (2005). "The Meaning of Open Standards". Proceedings of 38th 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] Sez, D.; Peris, M.; Roca, R.; Anes, D. (2007). Migracin al software libre. Gua de buenas prcticas. Instituto Tecnolgico de Informtica. 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 Garca Pastor, I. de la (2004). El plan de negocio: una herramienta indispensable. Instituto de Empresa. VV.AA. (2005). Migration guide. A guide to migrating the basic software components on server and workstation computers (2005). Berln: Bundesministerium des Innern. [Fecha de consulta: 20 de mayo de 2008]. http://www.kbst.bund.de/cln_012/nn_836802/SharedDocs/Anlagenkbst/Migrationsleitfaden/migration-guide-2ndedition__pdf,templateId=raw,property=publicationFile.pdf/migration-guide-2ndedition_pdf.pdf
FUOC P08/M2104/00604
156
Anexo
AnexoI:Licenciaslibresdesoftware A continuacin se presenta una lista breve de las principales licencias utilizadas para la produccin de software libre. Algunas de ellas se presentan con detalle en los materiales de las asignaturas de Introduccin al software libre y de Aspectos legales y de explotacin del software libre (2 parte). GNU/GPLv3 Las siglas GNU/GPL corresponden a la licencia General Public License del proyecto GNU. Mantiene una poltica de redistribucin robusta, llamada copyleft, que establece que todas las obras derivadas hereden la licencia original, incluso si se han combinado con otras. No se permite el enlace desde mdulos con una licencia diferente. La poltica de proteccin de los derechos originales del autor 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 versin 3 de GNU/GPL no es directamente compatible con la versin 2. Sin embargo, muchos programas licenciados bajo la segunda versin permiten la utilizacin, en los mismos trminos, de versiones posteriores de la licencia. GNU/LGPLv3 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 integracin de bibliotecas y libreras de software libre con otros tipos de licencia, en ocasiones propietarias, salvando las restricciones de las licencias GNU/GPL. La prctica ha permitido licenciar un buen nmero de programas, algunos de amplia difusin en la actualidad. Entre los programas licenciados bajo GNU/LGPL figura el paquete ofimtico OpenOffice.org. La versin 3 de GNU/LGPL no es directamente compatible con la versin 2. Sin embargo, muchos programas licenciados bajo la segunda versin permiten la utilizacin, en los mismos trminos, de versiones posteriores de la licencia. LicenciaBSD
Recurso web Encontraris ms informacin sobre la licencia GNU/LGPL en http:/ /www.gnu.org/licenses/ lgpl.html. Recurso web Encontraris una lista completa de compatibilidades en http://www.gnu.org/licenses/ license-list.html. Recurso web Encontraris ms informacin sobre la licencia GNU/ GPL en http://www.gnu.org/ licenses/gpl.html.
FUOC P08/M2104/00604
157
Las siglas BSD corresponden a la licencia Berkeley Software Distribution de la Universidad de Berkeley.
Recursos web Encontraris ms informacin de la licencia BSD en http://www.debian.org/misc/ bsd.license. Tambin podis encontrar un ejemplo de licencia derivada de la BSD original en http://www.freebsd.org/copyright/freebsd-license.html, llamada licencia BSD de dos clusulas (2-clause BSD license) debido a la abolicin de dos clusulas 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 poltica poco restrictiva con los derechos del usuario. Esta poltica, llamada copycenter en oposicin al trmino copyleft de las licencias GNU, permite entre otras cosas la aplicacin comercial del producto, su conversin a cdigo propietario y el enlace desde mdulos con licencia diferente. La licencia BSD original incorpora una clusula de publicidad que la hace incompatible con GNU/GPL. La clusula fue abolida en versiones posteriores, dando lugar a la llamada BSD de tres clusulas (en ingls, 3-clause BSD license), compatible con GNU/GPL. MPL1.1 Las siglas MPL corresponden a la licencia Mozilla Public License de la Fundacin Mozilla (Mozilla Foundation). Surgi de la iniciativa privada y es un hbrido 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 derivadas. Permite el enlace desde mdulos con licencia diferente. El artculo 13 permite licenciar una o ms partes del cdigo con una licencia diferente, llamada alternativa. Slo 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 tambin lo sean. LicenciaApache2.0 La licencia Apache es una licencia de la Fundacin de Software Apache (Apache Software Foundation). Es bastante similar a la licencia BSD y est considerada permisiva porque mantiene la posibilidad de establecer licencias propietarias a partir de obras derivadas, as como enlazarla desde mdulos con licencia diferente. El uso de patentes de esta licencia y las provisiones de indemnizacin la hacen compatible nicamente con la versin 3 de GNU/GPL, manteniendo la incompatibilidad con las dos versiones anteriores.
Pgina web Encontraris ms informacin sobre la licencia Apache en http://www.apache.org/licenses/LICENSE-2.0. Pgina web Encontraris ms informacin sobre la licencia MPL en http://www.mozilla.org/ MPL/MPL-1.1.html.
FUOC P08/M2104/00604
158
LicenciaX11 La licencia X11, llamada errneamente MIT License, es una licencia del Instituto Tecnolgico de Massachussetts (Massachussetts Institute of Technology, MIT). Es bastante similar a la licencia BSD de tres clusulas y est considerada permisiva porque permite licenciar obras derivadas como software propietario, as como enlazarla desde mdulos 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 continan utilizando, mientras que las versiones ms modernas utilizan la licencia XFree86 1.1, que es incompatible con GNU/GPL debido a los reconocimientos que se imponen en toda la documentacin. CDDL1.0 Las siglas CDDL corresponden a la licencia Common Development and Distribution License de SUN Microsystems. Est basada en la versin 1.1 de la licencia MPL. Las diferencias principales se centran en dos aspectos: El autor (o el poseedor de los derechos de autora) puede restringir la jurisdiccin legal de los derechos y los deberes de los usuarios del software.- El autor (o el poseedor de los derechos de autora) puede restringir la jurisdiccin legal de los derechos y los deberes de los usuarios del software. La licencia establece el requisito de identificar a todos los autores que contribuyen a las modificaciones introducidas en las obras derivadas. Permite el enlace desde mdulos con otra licencia, as como licenciar los derivados con una licencia diferente, eventualmente propietaria. Las caractersticas relacionadas con la propiedad intelectual la hacen incompatible con GNU/ GPL. CPL1.0 Las siglas CPL corresponden a la licencia Common Public License de IBM. Su objetivo es promocionar el desarrollo de cdigo libre, manteniendo la posibilidad de combinar el cdigo con otras licencias, incluyendo licencias propietarias, aunque impide licenciar los derivados con otro tipo de licencia. Tambin prohbe que el cdigo derivado infrinja las patentes del original, ya que obliga al pago de cualquier royalty. Es incompatible con GNU/GPL debido a las clusulas relacionadas con la legalidad de las obras derivadas.
Pgina web Encontraris ms informacin sobre la licencia CPL en http://www-128.ibm.com/ developerworks/library/oscpl.html. Pgina web Encontraris ms informacin sobre la licencia CDDL en http://www.sun.com/ cddl. Pgina web Encontraris ms informacin sobre el proyecto X.Org en http://www.x.org/. Pgina web Encontraris ms informacin sobre la licencia X11 en http://www.opensource.org/ licenses/mit-license.php.
FUOC P08/M2104/00604
159
s incompatible amb GNU/GPL degut a les clusules relacionades amb la legalitat de les obres derivades. EPL1.0 Las siglas EPL corresponden a la licencia Eclipse Public License de la Fundacin Eclipse (Eclipse Foundation). Se basa en la licencia CPL y mantiene una poltica permisiva orientada al negocio. 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 cdigo licenciado bajo EPL mantiene la licencia en las obras derivadas. Sin embargo, permite licenciar las adendas separadamente bajo otros tipos de licencia, eventualmente propietarias. Permite el enlace desde mdulos con licencia diferente. Las caractersticas relacionadas con la permisividad de la obra derivada y la gestin de la autora la hacen incompatible con GNU/GPL. AnexoII:Estndaresabiertos Definicin El proyecto SELF define un estndar abierto como un formato o protocolo que: est sujeto a la utilizacin y la evaluacin pblica, sin apremios, y de forma equitativa para todo el mundo; no tiene ningn componente o extensin que dependa de formatos o protocolos que no cumplan esta definicin de estndar abierto; no tiene clusulas tcnicas o legales que limiten su utilizacin por cualquiera de las partes o en cualquier modelo de negocio; ha sido gestionado y desarrollado independientemente de los intereses comerciales particulares y mediante un proceso abierto y equitativo entre competidores y terceras partes; y se encuentra disponible en mltiples implementaciones de diferentes vendedores, o bien en una sola implementacin disponible equitativamente para todas las partes. Sin embargo, no existe una definicin nica de estndar abierto, ya que cada organizacin preconiza un conjunto de caractersticas o prcticas adecuadas a sus objetivos particulares. Estas organizaciones pueden ser organizaciones de desarrollo de estndares, consejos supranacionales o gobiernos estatales. Algunas definiciones imponen la publicacin en condiciones razonables y no discriminatorias (en ingls, Reasonable And Non Discriminatory (RAND)), es decir, no totalmente exentas de royalties.
Ejemplo Como por ejemplo la definicin de la Unin Europea (http://europa.eu.int/idabc/ en/document/3761) o del ITU-T (http://www.itu.int/ ITU-T/othergroups/ipr-adhoc/ openstandards.html). Pgina web Encontraris ms informacin sobre los estndares abiertos del proyecto SELF en http://selfproject.eu/OSD. Pgina web Encontraris ms informacin sobre la licencia EPL en http://www.eclipse.org/org/ documents/epl-v10.php.
FUOC P08/M2104/00604
160
Otras definiciones inciden ms en las caractersticas del proceso que debe seguir un estndar 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 estndares de las tecnologas de la informacin son los siguientes: ANSI (American National Standards Institute): el Instituto Americano de Estndares Nacionales. ETSI (European Telecommunications Standards Institute): el Instituto Europeo de Estndares de Telecomunicacin (http://www.etsi.org/). FreeStandards (The Free Standards Group): organizacin independiente que promueve la utilizacin y la aceptacin de las tecnologas libres a travs de estndares. (http://www.freestandards.org/.) ICANN (Internet Corporation for Assigned Names and Numbers): Corporacin de Internet para la Asignacin de Nombres y Nmeros (http://www.icann.org/). IEC (International Electrotechnical Commission): Comisin Internacional de Electrotecnia (http://www.iec.ch/). IEEE (Institute of Electrical and Electronics Engineers, Inc): Instituto de Ingenieros Elctricos y Electrnicos (http://www.ieee.org/). IETF (Internet Engineering Task Force): Grupo de Trabajo en Ingeniera de Internet (http://www.ietf.org/). ISO (International Organization for Standardization): Organizacin Internacional para la Estandarizacin (http://www.iso.ch/). ITU (International Telecommunications Union): la Unin Internacional de Telecomunicaciones agrupa entidades de los sectores pblico y privado para coordinar las telecomunicaciones y los servicios globales (http://www.itu.int/). JXTA (JXTA Project): se trata de una combinacin de estndares abiertos de igual a igual (en ingls, 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 adopcin de los estndares e-business (http://www.oasisopen.org/).
Recursos web Encontraris ms informacin sobre estos procesos en: http://www.w3.org/Consortium/Process. http:// perens.com/OpenStandards/Definition.html. http://www.csrstds.com/ openstds.pdf.
Pgina web Encontraris ms informacin sobre ANSI en http:// www.ansi.org/.
FUOC P08/M2104/00604
161
OpenGroup (The Open Group): es un consorcio internacional de vendedores para el avance neutral de la tecnologa (http://www.opengroup.org/). RossettaNet (Open e-business process standards): es una asociacin para favorecer los estndares abiertos en el e-business (http://www.rosettanet.org/). VoiceXML (Voice XML Forum): es una organizacin 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 estndares en Internet (http://www.voicexml.org/). WS-I (Web Services Interoperability Organization): Organizacin para la Interoperabilidad de Servicios Web (http://www.ws-i.org/). Estndaresabiertos A continuacin se enumeran los principales estndares abiertos identificados por el proyecto SELF (http://selfproject.eu/en/system/files/D1_WP2.pdf). Textonoformateado ASCII, ISO8859 (http://www.iso.org/iso/iso_catalogue/catalogue_tc/ y UNICODE (http:// catalogue_detail.htm?csnumber=28245) www.unicode.org/). Textoconformato ODT (Open Document Text) y DocBook (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office). Textocientfico 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/). Imgenes(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/specgif89a.txt), BMP (Bitmap) (http://atlc.sourceforge.net/bmp.html). Imgenes(vectores) SVG (Scalable Vector Graphics) (http://svg.org/) y (http://www.w3.org/ Graphics/SVG/), ODG (Open Document Graphics).
FUOC P08/M2104/00604
162
Video OpenEXR (http://www.openexr.com/), Theora (http://theora.org/), RIFF (Resource Interchange File Format) AVI (http://msdn2.microsoft.com/enVideo Interleave) (http:// us/library/ms713231.aspx), (Audio
msdn2.microsoft.com/en-us/library/ms779636.aspx). Impresin 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/). Presentacin 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). Educaciiaprenentatge LOM (Learning Object Metadata) (http://zope.cetis.ac.uk/profiles/ Object Reference Model) IMS (http://www.imsglobal.org/ uklomcore), SCORM (Sharable Content
(http://www.conform2scorm.com/), learningdesign/index.html). Empresa
commoncartridge.html), LD (Learning Design) (http://www.imsglobal.org/
XBRL (Extensible Business Reporting Language) (http://www.xbrl.org/).

Implantación de Proyectos SL

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implantación de Proyectos SL

Cargado por

Copyright:

Formatos disponibles

Implantacin, proyectos y empresas de software libre

Amadeu Albs Raya scar David Snchez Jimnez

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Los objetivos de este mdulo siguiente son los siguientes:

Conocer los conceptos fundamentales de la implantacin de sistemas basados en software libre.

Implantacin, proyectos y empresas de software libre

1. Introduccin a la implantacin de sistemas basados en software libre

Implantacin, proyectos y empresas de software libre

El plan estratgico de la organizacin

Implantacin, proyectos y empresas de software libre (1)

Implantacin, proyectos y empresas de software libre

El trmino insourcing hace referencia a la delegacin o produccin interna de un proceso.

El trmino subcontratacin hace referencia a la delegacin o produccin externa de un proceso.

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Clasificacin por objetivo de los requerimientos

Se pueden definir tres grandes grupos de objetivos en proyectos de implantacin:

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

1.4. Gestin de proyectos en software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

3. Calcular los mrgenes de cada actividad

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

2. El proyecto de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Porque la documentacin de la etapa sintetiza el desarrollo y los resultados.

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre (8)

DAFO son las siglas de debilidades-amenazas-fortalezas-oportunidades. En ingls, SWOT.

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre

Implantacin, proyectos y empresas de software libre