Implantación de Proyectos SL

Implantación,
proyectos y
empresas de
software libre
Amadeu Albós Raya
Óscar David Sánchez Jiménez
P08/M2104/00604
© FUOC • P08/M2104/00604 Implantación, proyectos y empresas de software libre
Índice
Introducción.......................................................................................... 7
Objetivos................................................................................................. 9
1. Introducción a la implantación de sistemas basados en

software libre.................................................................................. 11
1.1. Conceptos básicos ..................................................................... 11
1.1.1. Definición ...................................................................... 11
1.1.2. El plan estratégico de la organización ........................... 12
1.1.3. Origen de la implantación de sistemas ......................... 13
1.1.4. Recursos de un proyecto de implantación de
sistemas .......................................................................... 14
1.1.5. Las principales etapas de un proyecto de
implantación de sistemas .............................................. 15
1.1.6. La viabilidad y la evaluación del proyecto .................... 17
1.1.7. Metodología del proyecto .............................................. 18
1.2. Tipología de proyectos .............................................................. 19
1.2.1. Clasificación por ámbito ............................................... 19
1.2.2. Clasificación por objetivo de los requerimientos .......... 22
1.3. Los sistemas basados en software libre ..................................... 26
1.4. Gestión de proyectos en software libre .................................... 28
1.4.1. Gestión del alcance ....................................................... 28
1.4.2. Gestión del tiempo ........................................................ 29
1.4.3. Gestión de la integración .............................................. 32
1.4.4. Gestión del coste ........................................................... 33
1.4.5. Gestión de la calidad ..................................................... 33
1.4.6. Gestión de recursos humanos ....................................... 34
1.4.7. Gestión de la comunicación .......................................... 34
1.4.8. Gestión de riesgos .......................................................... 35
1.4.9. Gestión de suministros .................................................. 36
2. El proyecto de software libre..................................................... 37

2.1. Ciclo de vida ............................................................................. 37
2.1.1. El proyecto ..................................................................... 38
2.1.2. Las etapas ....................................................................... 40
2.1.3. La ejecución ................................................................... 41
2.1.4. Los resultados ................................................................ 42
2.2. Estudio de la situación actual ................................................... 44
2.2.1. Identificación del sistema .............................................. 45
2.2.2. Desarrollo del caso de estudio ....................................... 45
2.2.3. Evaluación final ............................................................. 47
2.3. Estudio de los requisitos de la implantación ............................ 48

2.3.1. Identificación y definición ........................................... 50
2.3.2. Especificación y estructuración ..................................... 51
2.3.3. Verificación .................................................................... 52
2.3.4. Validación ...................................................................... 53
2.4. Análisis de las soluciones en software libre ............................. 56
2.4.1. Búsqueda de las soluciones .......................................... 57
2.4.2. Análisis y valoración de los candidatos ......................... 59
2.5. Formalización de la propuesta .................................................. 63
2.5.1. Preparación de la propuesta .......................................... 65
2.5.2. Diseño de la propuesta .................................................. 66
2.5.3. Presentación de la propuesta ......................................... 68
2.6. Desarrollo .................................................................................. 70
2.6.1. Dotación de recursos ..................................................... 72
2.6.2. Configuración y/o desarrollo de software ..................... 73
2.7. Implantación y migración ........................................................ 77
2.7.1. Tipos de migración ........................................................ 78
2.7.2. Estrategias de migración ................................................ 79
2.7.3. Inventario de hardware y software ................................ 81
2.7.4. Diagrama de red y diagrama de estructura .................... 83
2.7.5. Ejecución de la migración ............................................. 85
2.7.6. Evaluación de la migración ........................................... 87
2.7.7. Migración de los servicios de un sistema ...................... 88
2.8. Formación, comunicación y soporte al usuario ....................... 98
2.8.1. Formación ...................................................................... 99
2.8.2. Introducción del software libre ..................................... 100
2.8.3. Comunicación del proyecto .......................................... 101
2.8.4. Sistema de soporte al usuario ........................................ 102
3. La empresa del software libre.................................................... 104

3.1. Modelos de negocio .................................................................. 105
3.1.1. Desarrollo ....................................................................... 107
3.1.2. Consultoría .................................................................... 109
3.1.3. Instalación e integración ............................................... 111
3.1.4. Migración de sistemas ................................................... 113
3.1.5. Administración y mantenimiento de sistemas .............. 114
3.1.6. Soporte y formación ...................................................... 115
3.2. Plan de empresa ........................................................................ 117
3.2.1. Resumen ejecutivo ......................................................... 119
3.2.2. Introducción .................................................................. 120
3.2.3. Descripción del negocio ................................................ 122
3.2.4. Organización de la producción ..................................... 122
3.2.5. Organización interna y recursos humanos .................... 124
3.2.6. Estudio de mercado ....................................................... 125

3.2.7. Plan de marketing ......................................................... 128
3.2.8. Análisis económico-finaciero ......................................... 130
3.2.9. Forma legal .................................................................... 131
3.2.10. Gestión de riesgos .......................................................... 132
3.2.11. Resumen y evaluación ................................................... 132
3.2.12. Plan de empresa y software libre ................................... 133
3.3. Producción de software libre .................................................... 133
3.3.1. Creación y presentación del proyecto ........................... 135
3.3.2. Infraestructura ................................................................ 138
3.3.3. Organización de la comunidad ..................................... 142
3.3.4. Desarrollo ....................................................................... 144
3.3.5. Releasing y packaging....................................................... 147
3.3.6. Elección de licencias ...................................................... 150
Resumen.................................................................................................. 151
Glosario................................................................................................... 153
Bibliografía............................................................................................ 155
Anexo....................................................................................................... 156
© FUOC • P08/M2104/00604 7 Implantación, proyectos y empresas de software libre
Introducción
En este módulo nos adentraremos en la metodología propia de la implanta-

ción de sistemas basados en software libre en organizaciones y escenarios ge-
néricos, estableciendo las principales particularidades que guían el proyecto
y su desarrollo.
En la actualidad, la tecnología se posiciona como factor estratégico dentro de

la organización, ya sea pública o privada, ya sea de pequeño tamaño, medio
o grande. La implicación de la tecnología en todos los procesos funcionales
y operativos de la organización relaciona fuertemente su estado de funciona-
miento con la producción de la organización, por lo que hay que monitorizar
sistemáticamente la eficiencia y la eficacia del sistema con el objetivo de con-
trolar el rendimiento frente a la evolución de las necesidades estratégicas de
la organización.
En este sentido, la implantación de sistemas no se puede dejar al azar o a la

conveniencia de factores irrelevantes para la organización, ya que los resul-
tados pueden ser imprevisibles y tener consecuencias de diferente magnitud
para la organización. Por lo tanto, se establece la necesidad de proceder a la
implantación de un sistema con el rigor y la metodología propias de los ámbi-
tos científicos y tecnológicos, que establezcan un marco de apoyo que ofrezca
garantías para asumir la gestión de la complejidad, el desarrollo del proyecto
y la gestión de los riesgos inherentes tanto a la tecnología como al proceso de
implantación del sistema.
El objetivo central de este módulo es ofrecer una visión amplia y detallada de

los principales procesos relacionados con la implantación de sistemas basados
en software libre, tanto desde un ámbito genérico o abstracto, como desde una
perspectiva especializada en las características de la gestión funcional y opera-
tiva del proyecto ligado a la implantación del sistema, o bien considerando el
negocio del software libre como método válido y viable de empresa lucrativa.
Todos ellos requieren ser afrontados con una gestión metódica y rigurosa que
permita por una parte abordar satisfactoriamente la complejidad de solucionar
la problemática concreta del proyecto de implantación de sistemas, y por otra
parte, mantener controlados todos los riesgos potenciales que puedan hacer
fracasar el proyecto de alguna manera concreta, ya sea de forma prematura o
bien cuando el sistema ya se encuentra en explotación, ambas situaciones con
consecuencias importantes tanto para la organización, como para sus usuarios.
Los contenidos de este módulo se estructuran en tres unidades, que presentan

progresivamente los conceptos teóricos más importantes del proceso de im-
plantación de un sistema en una organización. En este sentido, los apartados
exponen la implantación de sistemas desde la perspectiva del software libre,

analizando las principales características que conducen a garantizar el éxito
del proyecto, tanto desde una perspectiva de gestión del proyecto como tal,
como de la implantación del software libre como negocio lucrativo. Seguida-
mente, se presenta un breve resumen de las principales características de cada
una de las unidades de este módulo.
El primer apartado, "Introducción a la implantación de sistemas", se dedica a

presentar de manera general la implantación de sistemas y las particularidades
del software libre. Se define la implantación de sistemas como una actuación
consecuente a la estrategia de la organización, detallando los diferentes orí-
genes que desencadenan la implantación, las principales etapas del proceso,
así como una clasificación de las principales tipologías en función del ámbito
del proyecto y de su objetivo. Se presentan las particularidades del software
libre, su repercusión en la implantación de sistemas, y la gestión funcional del
proyecto en términos de alcance, tiempo, integración, coste, calidad, recursos
humanos, comunicación y riesgos.
El segundo apartado, "El proyecto de software libre", se dedica a presentar de

manera exhaustiva el proyecto de implantación de software libre desde un
punto de vista metodológico. Se define el ciclo de vida del proyecto, sus prin-
cipales características, repercusiones, y relación con los objetivos. Se presentan
detalladamente las etapas de un proyecto de implantación: estudio de la situa-
ción actual, estudio de las incidencias en la implantación, análisis de las solu-
ciones en software libre, formalización de la propuesta, desarrollo, implanta-
ción y migración, y finalmente, formación, comunicación y apoyo al usuario.
Se define y se presenta con detalle cada una de las etapas en relación con la
consecución de sus objetivos particulares y globales.
El tercer apartado, "La empresa del software libre", se dedica a presentar de ma-
nera exhaustiva la empresa basada en el software libre, como alternativa válida
y viable en venta de copias de software. Se presentan los principales modelos
de negocio relacionados con el software libre, basados principalmente en la
producción y venta de servicios complementarios. Finalmente, se presentan
de manera exhaustiva las características del plan de empresa del software libre,
en el cual se detallan aspectos como la definición, los objetivos, el alcance, la
organización, los recursos humanos y materiales, la producción, la evolución
de los productos, el seguimiento y control de calidad, las garantías y el apoyo
al usuario, la economía, la financiación y el estudio de viabilidad del proyecto.
Esperamos que la formalización conceptual, metodológica y práctica de los

principales aspectos ligados al proyecto de implantación de sistemas basados
en software libre os permita entender la necesidad y la importancia tanto del
proceso, como de las actuaciones que hay que llevar a cabo para garantizar la
consecución de los objetivos estratégicos del proyecto.
Objetivos
Los objetivos de este módulo siguiente son los siguientes:
1. Conocer los conceptos fundamentales de la implantación de sistemas ba-

sados en software libre.
2. Saber identificar los diferentes tipos de proyectos de implantación de sis-

temas basados en software libre.
3. Familiarizarse con las áreas de gestión de proyectos y sus particularidades

aplicadas al software libre.
4. Conocer los elementos principales de un proyecto de software libre.
5. Conocer las fases del ciclo de vida de un proyecto de software libre.
6. Aprender a preparar una propuesta de proyecto de software libre.
7. Conocer en detalle las características de un proyecto de migración a soft-

ware libre.
8. Aprender a planificar y ejecutar un proyecto de migración a software libre.
9. Conocer los modelos de negocio utilizados por las empresas de software

libre.
10. Familiarizarse con los elementos principales de un plan de empresa o ne-

gocio.
11. Aprender a crear un plan de empresa o negocio basado en software libre.
12. Conocer las características principales de la producción de software libre

y sus particularidades.
1. Introducción a la implantación de sistemas basados

en software libre
Este primer módulo de la asignatura de Implantación de sistemas de software

libre proporciona las bases para conocer los principales conceptos implicados
en la implantación de sistemas en general, y su aplicación al software libre en
particular.
El módulo se inicia con un repaso de los conceptos básicos de los proyectos

de implantación de sistemas, con la caracterización de las diferentes fases del
proceso desde un punto de vista metodológico y funcional y el análisis de la
estrecha relación entre los objetivos estratégicos de la organización y el pro-
yecto de implantación.
Después, se presenta una clasificación de los tipos de proyectos de implanta-

ción más habituales, indicando las principales características y diferencias en-
tre ellos y analizando detenidamente las implicaciones en los objetivos del
proyecto y en su desarrollo.
Una vez se han revisado los conceptos básicos de la implantación de sistemas y

los diferentes tipos de proyectos que incluye, se presentan las particularidades
de la implantación de sistemas en software libre. Se analizarán los principales
factores que influyen en el proyecto y las ventajas y los inconvenientes de la
implantación al utilizar software libre.
Finalmente, se repasarán los conceptos básicos de la gestión de proyectos y

se ampliarán los modelos clásicos para adecuarlos a las particularidades de las
implantaciones basadas en software libre.
1.1. Conceptos básicos
En este primer apartado repasaremos los conceptos básicos de la implantación

de sistemas, desde su definición conceptual hasta las principales fases que la
constituyen, sin olvidar los aspectos metodológicos, estratégicos y organiza-
cionales.
1.1.1. Definición
Históricamente, la implantación de sistemas siempre ha estado estrechamente

ligada a la evolución de la tecnología y su difusión popular. De hecho, si se
caracteriza el concepto de manera global, cualquier innovación, tecnológica o
no, que se quiera difundir fuera del ámbito estricto de sus creadores requiere
seguir un proceso de implantación.
El hecho de corresponder a una implantación tecnológica implica la conside-

ración que debe prestarse a algunos aspectos esenciales, como el impacto en
la organización y en los usuarios directos, pero también en los usuarios indi-
rectos y en los clientes, por ejemplo. Además, actualmente se considera la tec-
nología (entendida desde un punto de vista global y genérico) como un factor
decisivo en la evolución competitiva de la organización..
En este sentido, la implantación de sistemas es el proceso por el cual

se instauran una o más novedades tecnológicas en una organización,
como resultado de una actuación que deriva de su plan estratégico.
De acuerdo con esta definición, la implantación de sistemas tecnológicos de-

riva de una voluntad estratégica de la organización para alcanzar nuevos hitos,
el objetivo de los cuales puede ser muy diverso en función del ámbito de la
misma organización.
Se puede ilustrar este concepto con dos ejemplos de ámbitos diferentes:
• Una empresa, en tanto que organización con ánimo de lucro, puede ac-
tuar sobre la tecnología que utiliza con el objetivo de mejorar su competi-
tividad y así optar a obtener más cuota de mercado, puesto que así puede
ofrecer un producto más innovador o adecuado a nuevas demandas.
• Una administración pública, en tanto que organización sin ánimo de lu-

cro, puede actuar sobre la tecnología a la cual tiene acceso la región que
administra, con el objetivo de ofrecer herramientas competitivas para mi-
nimizar la fractura digital y desarrollar la economía en este sector.
1.1.2. El plan estratégico de la organización
En el anterior apartado se ha hecho referencia al plan estratégico de la organi-

zación y a la importancia de su papel en la implantación de sistemas.
El plan estratégico de la organización es un conjunto de propuestas que

definen los objetivos o tendencias de la organización en el futuro. Acos-
tumbra a ser quinquenal, y tiene que desarrollarse posteriormente en
las diferentes áreas o departamentos funcionales de la organización.
El objetivo principal del plan es minimizar los riesgos y maximizar los resul-
tados de la implantación, mediante el establecimiento de tendencias reales,
asequibles y mesurables, fruto de la relación entre la organización y el ámbito
en el cual actúa.
1 (1)
Muchas veces, se utiliza el análisis DAFO como herramienta de diagnóstico DAFO es la sigla de debilidades,
amenazas, fortalezas y oportunida-
de la situación actual de la organización, que concreta en una sola tabla los des. En inglés, SWOT (strengths,
principales factores que influyen en el funcionamiento estructural de la orga- weaknesses, opportunities, threats).
nización en su entorno, en un momento dado.
Si se considera que el sistema que se tiene que implantar debe responder a las
necesidades actuales y futuras de la organización, se muestra la importancia
del vínculo entre el plan estratégico de la organización y el proyecto de im-
plantación.
El plan estratégico de la organización evoluciona con el tiempo, adaptándo-

la dinámicamente a los cambios del entorno en el cual actúa. De la misma
manera, el sistema de la organización tiene que evolucionar con los cambios
estratégicos y tiene que concluir algunas de las actuaciones emprendidas con
un nuevo proyecto de implantación de sistemas.
1.1.3. Origen de la implantación de sistemas
En los párrafos anteriores hemos visto el vínculo existente entre el proyecto

de implantación y el plan estratégico de la organización. Una organización no
pone en marcha un proyecto de implantación sin haber determinado que es
necesario llevarlo a cabo para su estrategia particular.
Así pues, la implantación de un sistema requiere haber constatado ca-

rencias en el sistema actual de la organización, aunque también puede
ser el objetivo de una implantación en organizaciones de nueva crea-
ción o sin posicionamiento tecnológico previo.
A grandes rasgos, se pueden considerar cuatro orígenes genéricos que pueden

desencadenar una nueva implantación de sistemas:
• Detección� de� problemas: puede haber casos diversos de mal funciona-

miento del sistema actual, lo que compromete el trabajo habitual de los
usuarios y la fiabilidad del propio sistema.
En estos casos, el plan estratégico se ve afectado principalmente por la
pérdida de rendimiento y eficiencia de la organización.
Un ejemplo de esta situación podrían ser los errores de programación que
comporten cálculos inexactos, errores de acceso o el bloqueo del sistema.
• Evolución�del�sistema: se trata de situaciones de obsolescencia funcional

del sistema actual, lo que compromete el funcionamiento de la organiza-
ción por falta de funcionalidades adecuadas a las crecientes incidencias en
la organización.
En estos casos, el plan estratégico se ve afectado por la pérdida de eficacia

de la organización. Un ejemplo de esta situación podría ser la necesidad
de ampliar las funcionalidades ante un cambio de legislación.
• Mejora�del�sistema: se trata de situaciones de obsolescencia estructural del

sistema actual, lo que compromete el funcionamiento de la organización
por falta de rendimiento de la plataforma del sistema actual.
En estos casos, el plan estratégico se ve afectado por la pérdida de rendi-
miento y eficiencia de la organización. Un ejemplo de esta situación po-
dría ser la falta de integración a nuevos sistemas operativos o hardware
diverso.
• Nueva�actuación�estratégica: encontramos las posibles actualizaciones,

modificaciones o novedades del plan estratégico de la organización que
no son cubiertas por el sistema actual.
En estos casos, el plan estratégico se ve afectado por la pérdida de eficacia
de la organización. Un ejemplo de esta situación podría ser la ampliación
de los servicios ofrecidos o del mercado objetivo.
La lista de posibles orígenes presentada en los párrafos anteriores no es exhaus-

tiva, pero explica las principales razones plausibles que pueden desencadenar
una implantación. Asimismo, los diferentes casos no son excluyentes los unos
de los otros, sino que su coincidencia puede depender en gran medida de la
evolución de la propia organización y de su sistema.
1.1.4. Recursos de un proyecto de implantación de sistemas
(2)
Habitualmente, una vez se ha detectado la necesidad de actuar sobre el siste- El término insourcing hace refe-
rencia a la delegación o produc-
ma actual para adecuarlo al plan estratégico de la organización, se dota de re-
ción interna de un proceso.
cursos al nuevo proyecto de implantación de sistemas. Los recursos se suelen
traducir inicialmente en disponibilidad horaria de una o más personas para
dedicarse al proyecto, con la repercusión económica que implica tal hecho en
el funcionamiento habitual de la organización (insourcing2).
(3)
Algunas organizaciones prefieren dejar esta tarea a profesionales externos (sub- El término subcontratación hace
3 referencia a la delegación o pro-
contratación o outsourcing ) por cuestiones de objetividad funcional, de capa- ducción externa de un proceso.
cidad de producción o de dedicación temporal. En estas circunstancias, la de-
dicación temporal de la organización en el proyecto no se anula completa-
mente, sólo disminuye en la medida en que aumenta la dedicación externa,
ya que tanto la organización como el profesional externo se necesitan mutua-
mente con el fin de completar el proyecto con éxito.
Uno de los puntos importantes del proyecto de implantación, independiente-

mente del formato final de ejecución, es la creación del comité supervisor o de
seguimiento del proyecto (comité ejecutivo en algunas organizaciones). Este
comité es el encargado de velar por una ejecución metodológica del proyecto
y por un avance del mismo adecuado, progresivo y sostenido en el tiempo.
Normalmente, el comité de supervisión está formado por personas de las di-

ferentes áreas afectadas por la implantación, principalmente directivos y jefes
de departamento. Si la organización hace uso de profesionales externos para
gestionar la implantación, éstos también forman parte del comité. Aunque
la dedicación de la mayoría de personas involucradas en el comité es parcial,
suele haber al menos un miembro con plena dedicación al proyecto, con el
objetivo de hacer el seguimiento exhaustivo.
El rol de los recursos en la implantación de un sistema es doblemente impor-

tante:
• Por una parte, porque de la asignación de los recursos humanos dependerá

la cantidad y la calidad en el análisis y diseño de implantación del sistema.
• Por otra parte, porque de la asignación de recursos materiales dependerá

la cantidad y la calidad del sistema a implantar.
En cualquier caso, la dotación de recursos en un proyecto de implantación de

sistemas tiene una traducción económica directa para la organización.
1.1.5. Las principales etapas de un proyecto de implantación de

sistemas
Como ya se ha comentado anteriormente, el proyecto de implantación de sis-

temas es un proceso metodológico que hay que abordar para ajustar el sistema
al plan estratégico. Este proceso se tiene que llevar a cabo con el suficiente
cuidado y dedicación para garantizar el éxito del proyecto.
Desde una perspectiva genérica, se pueden considerar cuatro grandes

fases en el proceso de implantación de sistemas: análisis del sistema
actual, diseño del nuevo sistema, desarrollo e implantación del sistema.
Análisis�del�sistema�actual
Todo proyecto de implantación se inicia con el estudio y análisis del estado

actual de la organización en los términos que prefigura la actuación estratégi-
ca. Se pueden identificar dos situaciones iniciales diferentes:
• Si la organización dispone de un sistema implantado, se evalúan las ca-

racterísticas recopilando la información y la estructura de los elementos
que influyen en la actuación estratégica. El objetivo será crear un marco
abstracto de adecuación del sistema a la nueva estrategia.
• Si la organización no dispone de un sistema implantado (o es de nueva

creación), hay que evaluar las características del entorno de actuación que
son objeto del ámbito estratégico de funcionamiento de la organización.
Habrá que crear un marco abstracto de objetivos que se tendrán que al-
canzar con el proyecto de implantación.
En cualquier caso, esta etapa define y determina la problemática a la cual se

enfrentará el proyecto de implantación, con la selección de los diferentes ob-
jetivos de la actuación estratégica. Se evalúan aspectos como el historial del
sistema, la estructura y funcionamiento o la evolución de las incidencias y el
volumen de trabajo a lo largo del tiempo. Muchos de estos resultados se pre-
sentan en forma de gráficos o diagramas.
Esta etapa finaliza con la presentación de las conclusiones del estudio y análisis
del estado actual, en las que se valora la idoneidad del sistema para afrontar
los nuevos retos estratégicos.
Diseño�del�nuevo�sistema
Una vez se ha evaluado la situación inicial de la organización y se han defi-

nido los principales puntos de actuación estratégicos, y después de recibir la
confirmación del seguimiento por parte del comité ejecutivo del proyecto, se
inicia el diseño del nuevo sistema.
Esta etapa empieza con el análisis exhaustivo de las incidencias que tiene que
resolver la nueva implantación de acuerdo con las actuaciones estratégicas de-
finidas. A partir de estas incidencias surgirán diferentes soluciones o alterna-
tivas a implantar que habrá que analizar individualmente para determinar la
idoneidad, los costes, las ventajas y los inconvenientes, tanto tangibles como
intangibles. En función del tipo de proyecto y de actuación estratégica, esta
valoración se extiende a un periodo quinquenal.
La elección de la solución tiene que ser metodológica y objetiva, buscando

maximizar las ventajas y minimizar los inconvenientes, tanto de la implan-
tación de la solución como de su funcionamiento habitual. Algunos criterios
decisorios pueden relacionarse con la extensión de la actuación, el rendimien-
to, el equipo requerido, los requisitos que cubre, el soporte del proveedor, la
disponibilidad tanto del equipo como del soporte o el mantenimiento nece-
sario a lo largo del tiempo.
Desarrollo�del�nuevo�sistema
Después de recibir la confirmación del seguimiento del proyecto por parte del
comité de supervisión, se inicia el desarrollo del nuevo sistema.
El desarrollo del sistema o la adaptación de las soluciones propuestas sigue Ved también
el ciclo de vida más adecuado al objeto del proyecto, alguno de los cuales
En la asignatura de Ingenie-
ha sido estudiado en otras asignaturas. Al final de esta etapa se obtiene un ría del software en entornos de
sistema preparado para ser implantado en la organización que da solución a software libre podéis encontrar
más información sobre el ciclo
las incidencias estratégicas observadas en la etapa anterior. de vida de desarrollo de soft-
ware.
Implantación�del�sistema
Cuando se dispone del nuevo sistema, se inicia la fase de implantación, que

consiste en la puesta en marcha del sistema dentro de la organización.
En esta fase se finaliza la adecuación y la integración del nuevo sistema en el

entorno real. Forma parte de esta fase la formación de los usuarios, las pruebas
piloto y de integración del sistema con los usuarios finales y la conversión y
liberación final del nuevo sistema.
En caso de que la organización disponga de un sistema implantado, se tiene

que considerar además la migración entre el antiguo sistema y el nuevo. La
migración consiste en la transferencia del estado actual del sistema en funcio-
namiento al nuevo sistema. Normalmente, el traspaso de datos es la tarea más
importante de la migración, ya que la transferencia no tiene que impactar en
el funcionamiento habitual de la organización.
Al final de esta etapa se obtiene la implantación definitiva del nuevo sistema,

la migración de los datos y la formación de los usuarios. Es decir, se ha com-
pletado la instauración de los elementos necesarios para hacer frente a la ac-
tuación estratégica que se había definido inicialmente.
Aunque con la implantación del sistema se cierra una parte importante del
proyecto de implantación, el mantenimiento y la constante evaluación de la
viabilidad del sistema continúan activos como en todo proyecto, especialmen-
te si se considera la nueva implantación como factor estratégico para la com-
petitividad de la organización.
1.1.6. La viabilidad y la evaluación del proyecto
En el apartado anterior se han descrito globalmente las principales fases de

las que se compone un proyecto de implantación de sistemas, pero además
hay que señalar también la importancia de al menos dos puntos de control
del proyecto.
El primero de ellos trata de la viabilidad y continuación del proyecto, y se

estructura en dos hitos:
• El primer hito tiene lugar después de la etapa de análisis del estado actual,
en la cual se analiza y se discute el estado actual del sistema con respecto
a la actuación estratégica.
• El segundo hito tiene lugar después de la etapa de diseño, en la cual se
analizan y se discuten las soluciones propuestas.
Por ejemplo, se puede cuestionar la conveniencia de continuar el proyecto

teniendo en cuenta las implicaciones económicas que supone su desarrollo.
El segundo punto de control trata de la evaluación del proyecto, y se enmarca Corte longitudinal
temporalmente después de la implantación definitiva del sistema en la orga-
Un corte longitudinal hace re-
nización. En este hito se analizan las repercusiones reales del nuevo sistema ferencia a que la observación
una vez se ha finalizado la implantación, evaluando los factores de impacto de los mensurables no es única
en el tiempo, sino que la ob-
medibles descritos en la actuación estratégica que ha emprendido el proceso servación se repite diversas ve-
ces durante un periodo defini-
de implantación. El objetivo es evaluar el grado de cumplimiento del nuevo do previamente.
sistema con respecto a la estrategia de la organización. La observación de estos
mensurables se realiza en formato de corte longitudinal.
Por ejemplo, se puede evaluar el impacto que el nuevo sistema ha tenido en la

capacidad productiva de la organización o en la captación de clientes nuevos.
1.1.7. Metodología del proyecto
Como en todo proyecto estratégico, la implantación de sistemas se tiene que

realizar de manera metodológica, estructurada y ordenada. La importancia del
resultado del proyecto para la evolución de la organización promueve la pre-
cisión con la cual se tiene que desarrollar.
A modo de ejemplo, este concepto se puede contrastar con la metodología

que se aplica al ciclo de vida en el desarrollo de un software y la importancia
de las fases de análisis conceptual y el diseño de la solución. En esta área, se
reconoce la problemática que proviene de no haber detectado una deficiencia
en las etapas de análisis y diseño. Globalmente, se considera que solucionar
un problema de diseño detectado en la etapa de desarrollo puede tener una
relación de coste de uno a diez.
De la misma manera, el proyecto de implantación de sistemas requiere la má-

xima precisión en las fases de análisis y diseño, vistas las implicaciones estra-
tégicas que tendrá la nueva implantación en la evolución de la organización.
La ejecución de las etapas descritas en los apartados anteriores tiene un com-

portamiento secuencial en el tiempo, inherente a su propio objetivo, pero aun
así se puede especializar la metodología de ejecución de cada etapa con el fin
de alcanzar los objetivos de manera más eficiente. De esta manera, y a modo
de ejemplo, se puede considerar la distribución siguiente:
• La fase de análisis del sistema actual puede seguir un esquema iterativo,

con realimentación de los resultados que se obtienen en el estudio.
(4)
• Las fases de diseño y desarrollo pueden seguir un esquema XP4 si se tra- XP son las siglas de eXtreme Pro-
gramming, una metodología ágil
ta de desarrollar software, o clásico si se trata de una implantación de in- para el desarrollo de software.
fraestructura.
• La fase de implantación puede seguir un esquema iterativo si la implanta-

ción afecta a diversas unidades, considerando la posibilidad de mantener
más de una línea de implantación por unidad de tiempo.
En cualquier caso, hay que adaptar la metodología de cada etapa a la conve-

niencia del proyecto y de la organización, siempre con el objetivo de maximi-
zar la eficiencia y minimizar el impacto negativo.
1.2. Tipología de proyectos
En este apartado se presenta una clasificación general de los diferentes tipos

de proyectos de implantación y se expondrán las diferentes particularidades y
las principales implicaciones en el desarrollo del proyecto.
Se detallan dos clasificaciones diferentes, primero según el ámbito de actua-

ción del proyecto, es decir, la repercusión y alcance de la implantación, y des-
pués según el objeto del proyecto, es decir, el contenido de la implantación.
No se tiene que entender esta clasificación como una estructura rígida, ya que
la diversidad real de los proyectos permite la combinación de diferentes tipo-
logías.
1.2.1. Clasificación por ámbito
Se pueden definir tres grandes ámbitos de actuación en los proyectos de im-

plantación:
1)�Interno
Los proyectos de ámbito interno tienen por objetivo implantar un sis-

tema local en la organización que sobre todo se utilizará internamente.
Por ejemplo, se pueden considerar de ámbito interno proyectos de implanta-

ción de servicios de red local (servicios de directorio, de autentificación o de
compartición de datos), de implantación de herramientas de trabajo en grupos
locales (correo interno o herramientas de grupo –groupware–) o de implanta-
ción de herramientas de gestión interna (sistemas ERP).
El objetivo estratégico de este tipo de proyectos es la mejora funcional interna,

en términos de eficiencia y eficacia del trabajo, mediante la renovación tecno-
lógica. Su origen se relaciona normalmente con escenarios en que el sistema
actual presenta deficiencias funcionales o falta de fiabilidad.
A continuación se presentan las principales implicaciones en el desarrollo del

proyecto.
• Evaluación�del�sistema�actual: Esta etapa plantea principalmente la eva-

luación del sistema desde un punto de vista funcional, con la localización
y evaluación de los aspectos del sistema que puedan presentar problemas,
teniendo siempre como referencia la actuación estratégica que ha previsto
la organización.
• Diseño�del�nuevo�sistema: El análisis de incidencias hecho en la etapa

de diseño tiene que permitir contraponer dos alternativas para afrontar la
implantación: por un lado, la evolución del sistema actual y, por otro, su
renovación en profundidad.
Mientras que la evolución busca la actualización parcial del sistema actual
para alargar su vida útil, la renovación en profundidad implica cambios
en diversos elementos del sistema (hardware y/o software).
• Desarrollo�del�nuevo�sistema: La etapa de desarrollo se mantiene sin cam-

bios importantes. En cualquier caso, el alcance local del proyecto puede
ayudar a su concreción y resolución estratégica.
• Implantación: El ámbito interno del proyecto puede ayudar a la implan-

tación progresiva (tiempo y/o servicios) que, conjuntamente con la for-
mación del personal, tendrá que ayudar a crear un clima de aceptación
mientras se garantiza el funcionamiento diario de la organización.
2)�Externo
Los proyectos de ámbito externo tienen por objetivo implantar en la

organización un sistema de utilización principalmente pública, que re-
lacione agentes externos con la organización. La ubicación del sistema
puede ser local o remota.
Por ejemplo, se pueden considerar de ámbito externo proyectos de implanta-

ción de intranets o extranets corporativas (acceso personalizado a trabajado-
res, clientes o proveedores) o de implantación de administración pública elec-
trónica (administración electrónica o voto electrónico).
El objetivo estratégico de este tipo de proyectos es la mejora funcional de la

organización con el exterior, en términos de eficacia y eficiencia de la comu-
nicación, mediante la renovación tecnológica. Su origen se relaciona normal-
mente con escenarios en los cuales la gestión de la relación digital con terce-
ros es compleja o poco eficiente, y también en casos de mejora de la imagen
corporativa y del mercado objetivo.

proyecto.

luación del sistema desde un punto de vista relacional, comunicativo e
interactivo. La recolección de datos no se puede restringir únicamente al
interior de la organización, de manera que hará falta el contacto con agen-
tes externos. Tanto si existe un sistema implantado como si no, el objetivo
de la actuación estratégica será evidenciar las carencias y debilidades de la
actual implementación relacional.
• Diseño�del�nuevo�sistema: El diseño del nuevo sistema tiene que respon-

der principalmente a dos tipos de objetivos, por una parte la funcionalidad
del usuario en términos de eficiencia y eficacia y, por otra, las considera-
ciones relativas a la imagen corporativa que la organización quiere trans-
mitir en el mercado objetivo.

bios importantes. En cualquier caso, hay que destacar que la gestión de la
seguridad es de especial importancia en este tipo de proyectos.
• Implantación: La implantación definitiva de estos sistemas se puede ha-

cer en dos fases, en un primer momento se puede poner en marcha el sis-
tema básico, mientras que la actualización de servicios y contenidos puede
ser progresiva en el tiempo, considerando las valoraciones de los usuarios
externos sobre los cambios producidos (feedback).
3)�Productivo
Los proyectos de ámbito productivo tienen por objetivo implantar un

sistema en un entorno diferente al de la organización que gestiona y/o
desarrolla el proyecto (subcontratación).
Por ejemplo, se pueden considerar de ámbito productivo proyectos de implan-

tación de software de base (sistemas operativos), de implantación de software
especializado (herramientas ofimáticas, contables, de facturación, etc.) o de
implantación de servicios externalizados (subcontratación de servicios web).
El objetivo estratégico de este tipo de proyectos es responder a demandas o

necesidades de servicios tecnológicos de otras organizaciones o colectivos ex-
ternos de diversos ámbitos. Su origen se relaciona normalmente con escena-
rios ligados a oportunidades de cambio tecnológico y estratégico del mercado
objetivo.

proyecto.

luación del sistema bajo dos tendencias diferentes. Por una parte, los pro-
yectos especializados, en los cuales hay una organización con necesidades
estratégicas específicas por cubrir.
Por otra parte, los proyectos de implantación directa (sistemas operativos o
herramientas ofimáticas), destinados a producir soluciones genéricas ade-
cuadas a un conjunto amplio de mercado. En cualquier caso, se evidencia
la importancia del estudio del estado de la situación actual.
• Diseño�del�nuevo�sistema: La etapa de diseño no presenta cambios signi-

ficativos. El proyecto especializado se lleva a cabo siguiendo las conside-
raciones de proyecto interno o externo en la organización cliente, mien-
tras que el proyecto de implantación directa tiene que satisfacer las ne-
cesidades habituales de funcionamiento y/o presentar innovaciones. Hay
que destacar la importancia de la tecnología utilizada en el proyecto como
imagen corporativa de la organización.

bios importantes. Hay que destacar la importancia de que el desarrollo res-
ponda con eficiencia y eficacia a los objetivos de la organización cliente,
así como la necesidad de hacerlo en los plazos temporales estipulados.
• Implantación: Los proyectos especializados siguen una implantación de

acuerdo con la tipología de proyecto interno o externo, en la que se destaca
la importancia de la formación y la comunicación de los usuarios. Los pro-
yectos de implantación directa normalmente se implantan empaquetados
en forma de producto autoinstalable (en formato CD-ROM, DVD-ROM o
descargables desde Internet). Algunos servicios se pueden considerar com-
plementarios (formación, migración, etc.) y realizados bajo demanda por
la misma organización o por terceros.
1.2.2. Clasificación por objetivo de los requerimientos
Se pueden definir tres grandes grupos de objetivos en proyectos de implanta-

ción:
1)�Software
Los proyectos de desarrollo de software tienen por objetivo implantar

aplicaciones que respondan a determinadas exigencias. También se pue-
den considerar de este tipo los proyectos de adaptación, reingeniería o
integración de software o herramientas, como la adaptación de sistemas
operativos o la integración de paquetes de software especializado.
El objetivo estratégico que persiguen este tipo de proyectos es dar una respues-
ta tecnológica a una problemática funcional concreta. Su origen se relaciona
normalmente con escenarios de implantación de sistemas de automatización
de tareas, de soporte tecnológico eficiente a los usuarios o de evolución o re-
novación de software obsoleto.

proyecto.

luación del sistema desde un punto de vista funcional, evaluando la efi-
ciencia y la eficacia del conjunto con respecto a la actuación estratégica
que inicia el proyecto.
En los proyectos de creación de software nuevo o genérico, la evaluación
se centra en el estudio y análisis del estado actual del mercado objetivo y
de las tendencias que lo guían.
• Diseño�del�nuevo�sistema: La etapa de diseño se mantiene sin cambios Ved también

importantes con respecto al ciclo de vida de producción de software que
Con respecto al ciclo de vida
hemos estudiado en otras asignaturas. Hay que destacar la importancia de producción de software,
metodológica de las fases de análisis de necesidades y diseño del sistema, consultad la asignatura Inge-
niería del software en entornos
con el objetivo de minimizar los errores que se detecten en etapas poste- de software libre.
riores.
• Desarrollo�del�nuevo�sistema: La etapa de desarrollo también se mantiene

sin cambios importantes con respecto al ciclo de vida habitual de este tipo
de proyectos. Hay que remarcar la importancia de los mecanismos que
aseguren la calidad del código producido, así como la evolución del código
en versiones y revisiones.
• Implantación: De la etapa de implantación del sistema se pueden diferen-

ciar dos tendencias. Por una parte, el desarrollo de software que hay que
instalar en una organización, que seguirá el proceso habitual teniendo en
cuenta la eventual necesidad de emprender una migración en caso de que
haya un sistema implantado actualmente. Por otra parte, el software de
uso común o genérico normalmente se implanta empaquetado en forma
de producto autoinstalable, en formato CD-ROM, DVD-ROM o descarga-
ble desde Internet. Algunos servicios se pueden considerar complementa-

rios (formación, migración, etc.) y realizados bajo demanda por la misma
organización o por terceros.
2)�Infraestructura
Equipamiento funcional
Los proyectos de implantación de infraestructura tienen por objetivo de servicio básico
implantar sistemas de base estructural o arquitectural en un entorno
Es el caso, por ejemplo, de la
determinado. Normalmente, estos proyectos se relacionan con la im- instalación y configuración de
servidores o clientes, como
plantación de equipamiento funcional de servicio básico para la orga- sistemas operativos, software
nización. de ofimática, servicios de red
básicos (DNS, DHCP, etc.) o
avanzados (correo, groupware,
etc.).
El objetivo estratégico que persiguen este tipo de proyectos es ofrecer una base
tecnológica funcional y adecuada a los requisitos de la organización. Su origen
se relaciona normalmente con escenarios de nueva creación o de renovación
tecnológica por obsolescencia del sistema. Hay que tener en cuenta que la
infraestructura de la organización es su arquitectura básica funcional sobre la
cual se dispondrán el resto de elementos tecnológicos.

proyecto:

luación del sistema desde un punto de vista funcional, considerando as-
pectos como la eficiencia y la eficacia pero también la fiabilidad y la ade-
cuación a los nuevos estándares que impone la evolución tecnológica.
En los casos en que no haya un sistema ya implantado, se tendrán pre-
sentes principalmente las necesidades de la organización (en cantidad y
calidad), así como las tendencias y estándares actuales.
• Diseño�del�nuevo�sistema: La etapa de diseño se centra principalmente en

la investigación y estudio de las diferentes soluciones que ofrece el merca-
do, aunque no se puede descartar la creación o evolución de una solución
si las necesidades de la organización lo requieren. De la comparativa tiene
que surgir el producto más adecuado a la actuación estratégica, conside-
rando criterios de evaluación como la extensión, la eficiencia y eficacia de
la solución, las necesidades del equipamiento y el soporte, disponibilidad
y mantenimiento del producto.
• Desarrollo�del�nuevo�sistema: La etapa de desarrollo del sistema compor-

ta la preparación de los procedimientos para implantar la infraestructura,
considerando que algunas veces es necesaria la adecuación del producto o
el ajuste de ficheros de configuración.
• Implantación: Si el nuevo sistema sustituye uno anterior, hará falta un

proceso de migración de un sistema al otro. Sin embargo, en la implanta-
ción se pueden diferenciar dos fases: en primer lugar, la instalación y con-
figuración de las novedades en el nuevo sistema, y después la puesta en
funcionamiento y restauración del estado.
No hay que olvidar que, en este tipo de proyectos, la comunicación y la
formación de los usuarios es fundamental para la aceptación de las nove-
dades, así como la evaluación del funcionamiento una vez se ha puesto
en marcha.
3)�Migración�de�sistemas
Los proyectos de migración de sistemas tienen por objetivo trasladar o

transferir el estado de la arquitectura tecnológica actual a otra diferente.
Estos proyectos surgen de la actualización de un elemento principal del
sistema o más.
El objetivo estratégico que persiguen este tipo de proyectos es minimizar el

impacto de los cambios tecnológicos que puedan afectar al funcionamiento
de la organización. Su origen se relaciona normalmente con escenarios de im-
plantación de nuevos sistemas de software o de infraestructura, aunque tam-
bién pueden existir de manera independiente por sustitución de la plataforma
tecnológica física por motivos de rendimiento, fiabilidad u obsolescencia.

proyecto:

luación del sistema desde un punto de vista de salvaguardia de la configu-
ración y de los datos almacenados. Será importante proceder de manera
metodológica en la investigación y evaluación de los diferentes elementos
que será necesario migrar al nuevo sistema.
• Diseño�de�la�migración: La etapa de diseño normalmente se centra en

estudiar y analizar los métodos y procedimientos que habrá que imple-
mentar para transferir el estado entre los sistemas. Se pueden considerar
aspectos como la preparación de las copias de seguridad o el diseño de los
procedimientos para exportar o convertir los datos del sistema actual.
• Desarrollo� de� la� migración: El desarrollo de la migración comporta la

realización de todas aquellas tareas de salvaguardia de datos y configura-
ción, de exportación y conversión sobre el sistema actual. Hay que valorar
la importancia que tiene la ubicación temporal de su realización, con el
fin de garantizar el traspaso íntegro de datos sin impedir el funcionamien-
to de la organización. También hay que tener en cuenta las garantías de

seguridad que ofrece el soporte de la salvaguardia.
• Implantación: La implantación hace referencia a la puesta en marcha del

nuevo sistema y la restauración del estado del sistema anterior de la orga-
nización. Es importante que este proceso esté planificado temporalmente
de manera conjunta con la etapa de desarrollo de la migración, con el fin
de minimizar el impacto del cambio en el funcionamiento de la organi-
zación, aunque se puede prever la restauración progresiva de algunos ele-
mentos menos prioritarios. En este tipo de proyectos, la comunicación y la
colaboración con los usuarios es especialmente importante para cumplir
los objetivos de la migración con garantías de éxito.
1.3. Los sistemas basados en software libre
En este apartado se presentan las particularidades de la implantación de siste-

mas basados en software libre. Se analizan los principales factores que influyen
en el proyecto y los mitos, ventajas e inconvenientes de utilizarlo.
Cuando se habla de software libre generalmente se suele hacer referen-

cia a sus ventajas, bastante conocidas. Así, el software libre es de distri-
bución libre, seguro, de calidad, se basa en estándares abiertos, puede
utilizarse en cualquier lugar, se basa en la cultura de la colaboración y la
favorece, mejora la capacidad tecnológica, permite reducir costes fijos
y variables en los sistemas informáticos, reduce la dependencia de pro-
veedores y fomenta el desarrollo de las empresas locales.
Sin embargo, las empresas dedicadas a la implantación de sistemas basados en

software libre se encuentran con una serie de problemas que frenan el desa-
rrollo del sector (Sáez y otros).
En general, a fin de que una tecnología se desarrolle, es necesario que esta

tecnología sea viable comercialmente, es decir, que haya una oferta y una de-
manda, y económicamente, de manera que las empresas del sector obtengan
beneficios de la implantación de la tecnología.
Con respecto a la demanda, es decir, las empresas que podrían adoptar el

software libre, los principales obstáculos están relacionados con la piratería,
el miedo al cambio y la desconfianza. Las empresas confunden el software
libre con el gratuito, y algunas compañías descartan su implantación, o bien
porque no hay software libre con niveles de calidad parecidos o bien porque
no confían en que detrás haya empresas que garanticen el mantenimiento y
soporte de este software.
Con respecto a la oferta, es decir, las empresas proveedoras de aplicaciones y

servicios de software libre, los obstáculos son básicamente el miedo al cambio
y la falta de espíritu de cooperación.
Generalmente, las empresas de informática están acostumbradas a desarrollar

software a medida, sin suministrar las fuentes a sus clientes, y manteniendo
un modelo de pago por licencias de uso. Sin embargo, gracias a la aparición
del software libre, algunas empresas están viendo que puede ser un modelo
de negocio sostenible aquél que se basa en el cobro por servicios y no por li-
cencias, lo que los ha llevado a liberar parte del código que hasta hoy día ha-
brá sido privado. De esta manera, una posibilidad que inicialmente podría ser
utilizada por muchas empresas sería la de ofrecer dos soluciones a sus clien-
tes, la de propiedad (con coste de licencia) y la libre (normalmente, sin coste
de licencia). Éste es sólo uno de los muchos modelos de negocio asociados al
software libre.
Por otra parte, las empresas informáticas también están acostumbradas a de-
sarrollar software de manera individual, y en este sentido una opción mejor
sería la de apostar por el modelo cooperativo con el fin de desarrollarlo. Eso
implica reaprovechar el trabajo de los otros, colaborar y trasladar los ahorros
en licencias al cliente final.
Los proyectos basados en software libre pueden plantearse como proyectos

normales desde el punto de vista de la ingeniería del software y de la gestión
de proyectos. Sin embargo, un análisis más detallado revela algunas diferen-
cias y particularidades, cuyo tratamiento se aprende muchas veces con la ex-
periencia, y la omisión de las cuales puede afectar e incluso llevar al fracaso
a algunos proyectos.
En este contexto, la puesta en práctica de una metodología completa para la

implantación de sistemas basados en software libre es esencial, sobre todo por
dos motivos:
• Transmite más confianza�al�cliente con respecto a la calidad de los pro-

ductos y los procesos, tanto si se trata del desarrollo de un nuevo programa
o aplicación, de la migración de un sistema ya en funcionamiento o de la
puesta en marcha de uno nuevo.
• Permite que las empresas proveedoras sistematicen el procedimiento de
implantación� de� sistemas� basados� en� software� libre y se familiaricen
con sus particularidades, con la consiguiente mejora en la eficiencia y mi-
tigación del miedo al cambio.
1.4. Gestión de proyectos en software libre
La gestión de proyectos se divide en nueve áreas de conocimiento clá-

sicas:
• Alcance
• Tiempo
• Integración
• Coste
• Calidad
• Recursos humanos
• Comunicación
• Riesgos
• Suministros
En este apartado se revisará cada una de ellas y se estudiarán sus particulari-

dades cuando se aplican a los proyectos de implantación de sistemas de soft-
ware libre.
1.4.1. Gestión del alcance
La gestión del alcance consiste en la definición de los objetivos del proyecto,

de manera que sea posible verificar el cumplimiento y, eventualmente, cam-
biarlos. Dicho de otra manera, la gestión del alcance se ocupa de que el pro-
yecto lleve a cabo todo el trabajo necesario, y sólo el trabajo necesario, para
cumplir los objetivos marcados al inicio.
Definición�del�alcance�del�proyecto
Para definir el alcance de un proyecto, el jefe que lo gestiona tiene que esta-
blecer la estructura de desagregación del proyecto (EDP), con la cual el pro-
yecto queda dividido en paquetes de trabajo, representados habitualmente en
forma de árbol lógico. Un paquete de trabajo es la unidad más pequeña en
que se puede dividir un proyecto de manera que sea gestionable de indepen-
dientemente.
Así, se identificará todo lo que se tiene que hacer en el proyecto a través de su

correspondiente EDP, describiendo brevemente los paquetes de trabajo que lo
componen junto con los entregables que cada uno de ellos necesita o facilita.
Cambios�en�el�alcance�del�proyecto
A veces puede convenir modificar el alcance y los objetivos del proyecto mien-
tras se está ejecutando. Eso se puede deber a los motivos siguientes:
• Deficiencias en el plan de proyecto original, especialmente por una defi-

nición incorrecta del alcance.
• Cambios en las necesidades y requisitos planteados por el cliente en el
plan de proyecto inicial.
• Cambios en el contexto del proyecto y, por lo tanto, en las hipótesis con-
sideradas cuando se realizó el plan de proyecto inicial.
Estas contingencias pueden afectar de manera importante a la ejecución del

proyecto, modificando e incluso impidiendo la consecución de sus objetivos.
Por ello, el control de los cambios es esencial, y se tiene que tener en cuenta
en la gestión de riesgos.
Gestión�del�alcance�en�los�proyectos�basados�en�software�libre
La gestión del alcance en proyectos basados en software libre presenta las mis-
mas características que cualquier otro proyecto de software. Será fundamental
una captura y análisis detallado de los requisitos del cliente, y también de la
situación actual del sistema cuando se trate de proyectos de migración.
En general, la definición del alcance del proyecto basado en software libre de-
penderá de cuál sea la motivación del proyecto: reducción de costes, mejora
del sistema, independencia ante los distribuidores o regularización de la situa-
ción de las licencias de software.
Finalmente, es importante destacar que, a veces, el cliente puede no ser cons-

ciente de las consecuencias de los cambios en el proyecto, una vez ya se ha
puesto en marcha.
1.4.2. Gestión del tiempo
La gestión del tiempo tiene como objetivo asegurar que el proyecto se lleve a
cabo en los plazos previstos. Para eso habrá que definir la secuencia de activi-
dades que se tienen que realizar, así como su duración y coordinación.
Una buena planificación del tiempo es una herramienta fundamental en la di-

rección de un proyecto, ya que representa el modelo a partir del cual se llevará
a cabo y permite asegurar que se están alcanzando sus objetivos, facilita las
bases para realizar la integración del tiempo, los costes y los recursos y propor-
ciona un marco común para las diferentes personas y socios que participan.
Red�del�proyecto
A partir del EDP que hemos visto en el apartado anterior, se identificarán las
actividades necesarias para realizar el proyecto, teniendo presente que una
actividad es la parte de trabajo más pequeña en que se puede dividir el proyecto
con el fin de llevar a término la planificación.
A continuación, se identificará la secuencia en la cual se tienen que realizar

las actividades: aquéllas que son independientes y que pueden realizarse en
paralelo y aquéllas que son dependientes, es decir, que para su realización
necesitan el resultado de una actividad precedente.
Diagrama�de�Gantt
El diagrama de Gantt es el instrumento que permite resolver el problema de

la programación de actividades (es decir, su distribución conforme a un calen-
dario) y representar gráficamente la duración de cada actividad, sus fechas de
inicio y de final y, en consecuencia, el tiempo total requerido para la ejecución
del proyecto. Además, los diagramas de Gantt permiten controlar el progreso
del proyecto, ya que indican el porcentaje realizado por cada actividad y de-
tectan avances o retrasos en relación con la planificación inicial.
Un diagrama de Gantt consiste en un sistema de coordenadas en el cual se

representa:
• Eje horizontal: escala de tiempo, en las unidades más adecuadas al proyec-

to, habitualmente días, semanas o meses.
• Eje vertical: paquetes de trabajo, actividades y subactividades identificadas
en el EDP, cuya duración se representa sobre el eje horizontal.
La principal ventaja de los diagramas de Gantt es que no hace falta una gran
cantidad de información para utilizarlo; de hecho, basta con que exista un
plan no demasiado detallado del proyecto. Por ello, es un instrumento de uso
sencillo y es especialmente eficaz cuando se está planificando inicialmente
el proyecto. Sin embargo, una vez ha empezado el proyecto, y en especial si
éste presenta una complejidad elevada, el diagrama de Gantt puede resultar
confuso.
Método�del�camino�crítico�y�PERT
Con el fin de superar las limitaciones de los diagramas de Gantt, se han desa-
rrollado otros instrumentos, entre los cuales destacan los métodos de camino
crítico (CPM) y PERT.
El camino crítico en un proyecto es la sucesión de actividades que dan lugar al

máximo tiempo acumulado. Determina el tiempo más corto que tarda a rea-
lizarse el proyecto si disponemos de todos los recursos necesarios. Para eso se
tienen que identificar bien todas las actividades y debe conocerse su duración.
Con el fin de representar las actividades y las dependencias temporales se uti-

lizan grafos dirigidos, en los cuales cada flecha representa una actividad iden-
tificada por su nombre y duración, de manera que el avance del proyecto mo-
difica el estado. Cada estado se representa por un nodo entre dos o más flechas.
De esta manera hay tareas que se pueden realizar en paralelo y otras que no.
La principal diferencia entre el CPM y el PERT se encuentra en la estimación

del tiempo. El CPM considera que los tiempos de las actividades (m) se cono-
cen de manera exacta y varían según los recursos asignados. En cambio, el
PERT supone que el tiempo de las actividades (Te) es determinado por una
distribución de probabilidad dada por la duración estimada más probable (m),
la duración estimada más optimista (a) y la duración estimada más pesimista
(b). De esta manera los tiempos pesimistas y optimistas dan una medida de la
incertidumbre de cada actividad.
Para calcular el camino crítico se siguen los pasos siguientes:
1. Calcular Te o m para cada actividad, según el método utilizado.
2. Calcular las fechas mínimas de comienzo (early) de cada actividad (MIC) y

las fechas máximas de comienzo (last) de cada actividad (MAC).
Cálculo del MIC
El MIC de cada acontecimiento se calcula como el máximo de la duración de las activi-

dades anteriores más el MIC del acontecimiento anterior. El MAC es la fecha máxima
en la cual pueden cumplirse los acontecimientos sin representar un retraso en la finali-
zación del proyecto.
3. Calcular los márgenes de cada actividad
El margen de una actividad
El margen de una actividad es el suplemento de tiempo que tenemos para determinar

esta actividad:
• Margen de un acontecimiento: Hs = MAC del acontecimiento – MIC del aconteci-

miento.
• Margen de una actividad: Ht = MAC del acontecimiento posterior – MIC del aconte-
cimiento anterior – duración de la actividad.
4. Identificar el camino crítico del proyecto
Una actividad es crítica cuando no se pueden cambiar sus instantes de comien- Ved también
zo y finalización sin modificar la duración total del proyecto. Las actividades
Para profundizar en cada uno
críticas no tienen margen y la concatenación de actividades críticas es el ca- de estos métodos, se reco-
mienda consultar la bibliogra-
fía indicada al final del módu-
lo.
mino crítico. Dicho de otra manera, en una actividad crítica la fecha mínima
de comienzo coincide con la más tardía de comienzo, y la fecha más temprana
de finalización coincide con la fecha máxima de comienzo de la actividad.
Gestión�del�tiempo�en�los�proyectos�basados�en�software�libre
La gestión del tiempo en proyectos basados en software libre presenta en prin-

cipio las mismas características que cualquier otro proyecto de software.
En los proyectos de desarrollo de programas y aplicaciones en los cuales la

participación de la comunidad de desarrolladores de software libre tiene un
papel importante, es esencial calcular correctamente los plazos dedicados al
desarrollo del software. Por ello hace falta conocer los antecedentes de la co-
munidad y discutir el plan de implementación futuro. También es recomen-
dable implicarse en la comunidad y familiarizarse con su forma de trabajar
antes de iniciar el proyecto.
En los proyectos de migración es esencial dimensionar correctamente el tiem-

po necesario para llevar a cabo la formación de los usuarios, e incluso prever
cierta flexibilidad para realizar la migración de los usuarios.
En consecuencia, ciertos proyectos de software libre pueden tener asociada

una incertidumbre bastante alta, por lo que resulta recomendable la utiliza-
ción de la técnica PERT con la finalidad de caracterizar adecuadamente los es-
cenarios más optimistas y pesimistas en el plan de proyecto.
Hay numerosas aplicaciones libres que permiten la creación y mantenimiento Aplicaciones libres
de diagramas de Gantt y PERT.
Son aplicaciones libres, por
ejemplo, GanttProject (http://
1.4.3. Gestión de la integración ganttproject.sourceforge.net/
) o OpenWorkbench (http://
www.openworkbench.org/).
La gestión de la integración tiene como objetivo asegurar que las diferentes
partes del proyecto están coordinadas correctamente. Esto incluye el desarrollo
del plan del proyecto, el plan de ejecución y el control de los cambios que se
puedan llegar a producir.
Gestión�de�la�integración�en�los�proyectos�basados�en�software�libre
La gestión de la integración en proyectos basados en software libre presenta

en general las mismas características que cualquier otro proyecto de software,
pero conviene tener en cuenta ciertas particularidades.
En general, la integración en proyectos basados en software libre presenta cier-

tas ventajas con respecto a los proyectos basados en software propietario, fun-
damentalmente a causa del código abierto y del uso de estándares abiertos que
facilitarán la interoperabilidad de aplicaciones, sobre todo con aquéllas desa-
rrolladas fuera del proyecto.
En los proyectos de desarrollo realizados en colaboración con una comunidad

externa al proyecto, es importante hacer público y discutir el plan de imple-
mentación tanto del proyecto como de la comunidad, con el fin de identificar
posibles incompatibilidades que puedan dificultar la integración.
1.4.4. Gestión del coste
La gestión del coste tiene como objetivo que el proyecto se complete con el
presupuesto inicialmente aprobado. Ello comporta la planificación de los re-
cursos necesarios y la estimación y el control de los costes.
Gestión�del�coste�en�los�proyectos�basados�en�software�libre
La gestión del coste en proyectos basados en software libre difiere considera-

blemente de un proyecto basado en software propietario.
La principal diferencia reside en el coste de las licencias, que normalmente

será nulo para el software libre. En cambio, se tendrán en cuenta los costes
de servicios prestados por terceros, siguiendo cualquiera de los modelos de
negocio basados en software libre.
1.4.5. Gestión de la calidad
La gestión de la calidad tiene como objetivo que el proyecto satisfaga las ne-
cesidades para las cuales fue diseñado inicialmente. Para eso se tiene que pla-
near, asegurar y controlar continuamente la calidad del proyecto en relación
con estas necesidades.
Gestión�de�la�calidad�en�los�proyectos�basados�en�software�libre

Por una parte, se debe tener en cuenta la calidad desde el punto de vista del
usuario, con la adopción de los estándares necesarios en cada caso. Por otra
parte, en los proyectos en los cuales se trabaje con la comunidad de software
libre, sea contribuyendo a un proyecto ya existente o sea creando un de nuevo,
hay que tener en cuenta la calidad del código producido desde el punto de
vista de quien lo desarrolla.
Hay que respetar las recomendaciones de estilo de programación, convencio- Estilos de programación
nes de nombres, documentación, registros y formatos de error, idiomas, etc. estándar
En caso de que se trate de un nuevo proyecto, convendrá hacer públicas estas Hay que tener en cuenta que
recomendaciones. existen estilos de programa-
ción ya definidos y aceptados
por la comunidad que convie-
ne seguir, como las Java Code
1.4.6. Gestión de recursos humanos Conventions o Linux C kernel
style.
La gestión de recursos humanos tiene como objetivo la utilización más efi-

ciente posible de las personas que participan en el proyecto, y entre sus acti-
vidades hay el plan organizacional, la contratación de nuevos empleados y el
desarrollo de los equipos.
Gestión� de� los� recursos� humanos� en� los� proyectos� basados� en� software
libre

cipio las mismas características que cualquier otro proyecto de software, pero
conviene tener en cuenta ciertas particularidades.
Principalmente, se tendrá que evaluar la posible participación en la comuni-

dad de software libre y también la contribución efectiva que pueda tener esta
comunidad en el proyecto. En general, irá bien definir un responsable de las
relaciones con las comunidades de software libre asociadas al proyecto.
1.4.7. Gestión de la comunicación
La gestión de la comunicación tiene como objetivo asegurar la correcta gene-

ración, recolección, diseminación, almacenamiento y eliminación de la infor-
mación del proyecto, en unos plazos determinados.
Gestión�de�la�comunicación�en�los�proyectos�basados�en�software�libre
La gestión de la comunicación en proyectos basados en software libre presenta

en principio las mismas características que cualquier otro proyecto de softwa-
re. Es muy importante asegurar la comunicación y diseminación de la infor-
mación dentro del proyecto, especialmente cuando se colabora con la comu-
nidad de software libre. En caso de que no se trabaje con la comunidad de
software libre, pero se previera la posibilidad de liberar el código, o si el clien-
te deseara tener acceso al mismo, sería igualmente importante que el código
fuente se pudiera leer y estuviera bien documentado.
La configuración y utilización correcta de los forjas de software o entornos de Forjas de software

colaboración de desarrollo (CDE) tiene, por lo tanto, un papel fundamental. La
Podéis consultar ejemplos de
mayoría de forjas incorpora herramientas para la gestión general del proyecto, forjados de software o entor-
seguimiento de errores, foros, listas de correo, etc. De la misma manera, las nos de colaboración de desa-
rrollo en las siguientes webs:
forjas públicas disponen también de estas herramientas, y ofrecen la ventaja Gforge, LibreSource o Trac.
de ofrecer más visibilidad a la comunidad de software libre.
Web complementaria
Entre las herramientas de comunicación podemos destacar listas de correo,
canales IRC, blogs, foros y wikis. Es importante que las decisiones relevantes Podéis consultar un ejem-
plo de forja pública en
tomadas a través de estas herramientas se documenten adecuadamente y se la siguiente web: http://
pongan a disposición de todos los que las desarrollen. www.sourceforge.net.
Con respecto a la documentación, es recomendable definir las reglas a seguir

con el fin de elaborarla, así como las herramientas que se utilizarán para su
generación automática.
1.4.8. Gestión de riesgos
La gestión de riesgos tiene como objetivos identificar, analizar y dar respuesta

a los posibles acontecimientos que amenacen el plan del proyecto, en forma
de retrasos en el mismo y aumento de los costes.
Estos riesgos tienen que estar correctamente identificados y cuantificados, así

como los mecanismos de respuesta pertinentes. Un riesgo presenta siempre las
características de incertidumbre, ya que el acontecimiento que caracteriza al
riesgo puede ocurrir o no, y de pérdida, ya que si el acontecimiento finalmente
ocurre se producirán consecuencias negativas o pérdidas para el proyecto. Por
ello, con el fin de caracterizar los riesgos es esencial evaluar correctamente su
probabilidad y las pérdidas asociadas.
Existen múltiples clasificaciones de riesgos. Como primera aproximación, se

pueden considerar los siguientes tres tipos de riesgos:
• Riesgos de gestión, relacionados con problemas en la planificación tem-

poral, el presupuesto y la organización de personal y recursos.
• Riesgos técnicos, que amenazan la calidad y la planificación temporal del
proyecto y dificultan el desarrollo y la implantación del mismo. Los ries-
gos técnicos más frecuentes están asociados a problemas potenciales de
diseño, implementación, verificación o mantenimiento. Su origen suele
hallarse en la existencia de ambigüedades en requisitos y especificaciones
y en el uso de tecnologías anticuadas o demasiado nuevas.
• Riesgos de negocio, que amenazan la viabilidad del proyecto. Por ejemplo,
desarrollar un proyecto para el cual no existe bastante mercado o que no
encaja con la línea comercial de la empresa.
Gestión�de�riesgos�en�los�proyectos�basados�en�software�libre
La gestión del riesgo en proyectos basados en software libre presenta en prin-

Un ejemplo clásico de riesgo en los proyectos basados en software libre son

los que se relacionan con el miedo y la incertidumbre –tanto de la organiza-
ción como de los usuarios– del cambio tecnológico en una nueva plataforma,
eventualmente desconocida.
Convendrá asegurarse al inicio del proyecto de establecer métodos de comu-

nicación y formación para reducir los eventuales impactos negativos asocia-
dos al rechazo del cambio tecnológico. Una buena práctica es establecer un
periodo de presentación, difusión y formación de los usuarios, sostenido y
progresivo a lo largo de la implantación, que ofrezca tanto la visión global del
software libre como la de aplicaciones y herramientas concretas.
Otro ejemplo clásico de riesgo en los proyectos basados en software libre son
las posibles incompatibilidades legales entre licencias libres, de código desa-
rrollado y reutilizado.
Convendrá asegurarse al inicio del proyecto que las licencias que se aplican
a las diferentes partes del código son coherentes entre ellas, y que los planes
de desarrollo no producirán ninguna incompatibilidad. Esta misma compro-
bación se tiene que realizar antes de cada release. Una buena práctica es dis-
poner siempre de un mapa de licencias, que recoja la licencia bajo la cual se
distribuye cada uno de los paquetes de software y las interacciones entre cada
uno de ellos.
1.4.9. Gestión de suministros
La gestión de suministros tiene como objetivos garantizar que los materiales y

recursos necesarios para la ejecución del proyecto estén disponibles a tiempo
y en el lugar necesario.
Gestión�de�suministros�en�los�proyectos�basados�en�software�libre
La gestión de suministros en proyectos basados en software libre presenta en

principio las mismas características que cualquier otro proyecto de software.
La migración e implantación de un sistema basado en software libre suele ser

un buen momento para renovar equipos o para modificar la estructura de la
red de la organización, para lo cual el plan de proyecto debe tener en cuenta
los pedidos de nuevos equipos y material con el fin de tener en cuenta posibles
retrasos y evitarlos.
2. El proyecto de software libre
Un proyecto es un proceso de gestión de recursos organizado y estructurado

para alcanzar un determinado objetivo, normalmente estratégico. Mientras
que en la primera parte se han presentado los aspectos más importantes de la
gestión funcional de los recursos, este módulo centra su atención en las etapas
que tiene que seguir el proyecto para alcanzar sus objetivos.
En general, se pueden identificar siete etapas importantes en los proyectos de

implantación de sistemas de software libre:
• Estudio de la situación actual

• Estudio de los requisitos de la implantación
• Análisis de las soluciones en software libre
• Formalización de la propuesta
• Desarrollo
• Implantación y migración
• Formación, documentación y soporte al usuario
Como se puede observar, estas etapas son fruto del desarrollo de las fases pre-
sentadas en el primer apartado de esta unidad y de la aplicación particular alre-
dedor del software libre. Sin embargo, el desarrollo que se presenta es bastante
genérico y permite que se pueda aplicar a otros procesos de implantación.
En este apartado se presenta el ciclo de vida del proyecto y ofrece una visión
global del proceso, de las etapas y de su relación con la gestión del proyecto
y con los recursos que se dedican.
Los siete apartados siguientes se dedicarán a desarrollar detalladamente las

etapas del proyecto, enlazando y ampliando los conceptos ya presentados en
el primera parte de este módulo.
2.1. Ciclo de vida
En este primer apartado se presentan las principales características metodoló-

gicas y funcionales del ciclo de vida del proyecto, con el objetivo de propor-
cionar una visión global del proceso.
El ciclo de vida del proyecto enlaza los aspectos metódicos, inherentes al de-
sarrollo de las etapas de la implantación, con la gestión funcional del proyec-
to. En este sentido, el ciclo de vida guía la ejecución de las diferentes etapas a
través del tiempo y de los recursos disponibles.
Globalmente, el ciclo de vida de un proyecto tiene dos objetivos principales:
• Por una parte, establece las relaciones y dependencias entre las etapas, ya Ved también
sean temporales o funcionales.
Podéis conocer más detalles de
la gestión del riesgo consultan-
• Por otra parte, permite reducir el riesgo del proyecto gracias a la división do el apartado sobre gestión
de riesgos de la unidad ante-
de su complejidad. rior.
Con el ciclo de vida del proyecto se puede controlar la evolución de las eta-
pas, el calendario temporal de ejecución y el coste económico del proyecto.
Hay que destacar que la gestión del ciclo es dinámica, por lo que se pueden
tomar decisiones de modificación y adecuación a lo largo del tiempo con el
objetivo de reajustar la estimación de los parámetros iniciales en función de
los acontecimientos reales.
A grandes rasgos, hay cuatro aspectos importantes del ciclo de vida: el proyec-
to, las etapas, la ejecución y los resultados.
2.1.1. El proyecto
Ved también
El proyecto de implantación de sistemas, como cualquier otro proyecto,
se propone la consecución de un conjunto de objetivos en un tiempo Podéis conocer más detalles
de la gestión de los proyectos
determinado y con un conjunto de recursos determinado. consultando el apartado de
gestión de proyectos en soft-
ware libre de la unidad ante-
rior.
Normalmente, minimizar el tiempo o los recursos que se dedican al proyec-
to conducirá a minimizar los objetivos que se puedan alcanzar o a disminuir
su calidad, y viceversa. En cambio, minimizar el tiempo del proyecto mante-
niendo los objetivos del mismo requiere un aumento de los recursos que se
dedican. La gestión del proyecto busca el equilibrio más factible entre estos
tres elementos.
En cualquier caso, los cambios que se producen en la relación de estos tres

elementos tienen repercusiones económicas directas que habrá que asumir en
caso de actualización. En este sentido, la propia gestión del proyecto tiene aso-
ciado un coste económico desde el primer momento que se inicia el proyecto
(cuando se decide asignar tiempo de uno o más trabajadores para iniciar la
gestión).
Normalmente, los principales factores que influyen en el tiempo y en los re-

cursos necesarios para llevar a cabo el proyecto tienen relación con el tamaño
y la complejidad del sistema a implantar. En este sentido, las características del
software libre favorecen la reducción de los costes temporales y económicos
asociados al proyecto:
• Variedad�de�aplicaciones. La madurez del mercado de software libre ofre-

ce una amplia variedad de productos de implantación directa fiables, con-
sistentes y seguros.
• Coste�de�las�licencias. Normalmente, el software libre se puede conseguir

sin costes de licencia y se puede descargar directamente desde la web oficial
o desde otros depósitos públicos.
• Modificación�del�código�fuente. La apertura del código fuente permite la

ampliación, modificación y ajuste de los productos allí donde con modelos
de licencias de propiedad haría falta un desarrollo nuevo, si se quisiera
hacer evolucionar el producto.
Es importante destacar que el software libre también contribuye a disminuir

el riesgo global del proyecto, gracias a las características de libertad de visuali-
zación, utilización y modificación del código fuente, que permiten evaluar y
valorar en profundidad todos los aspectos de la aplicación.
Por otra parte, el proyecto se puede gestionar y ejecutar de manera interna

o externa a la organización. A grandes rasgos, se pueden distinguir dos casos
principales:
• Insourcing: corresponde a los casos en que la organización asume el desa-

rrollo del proyecto emprendido a partir de una actuación estratégica. Es
decir, el departamento de informática de la organización gestiona y ejecu-
ta el proyecto.
(5)
• Outsourcing�o�subcontratación: corresponde a los casos en que la organi- Por ejemplo, las consultorías tec-
nológicas ejecutan proyectos por
zación delega la gestión y el desarrollo del proyecto a una organización
cuenta ajena.
externa dedicada a la gestión y ejecución de proyectos5. Es decir, la orga-
nización reduce su exposición directa al desarrollo del proyecto.
En este sentido, el formato de desarrollo del proyecto se decidirá consideran-

do la capacidad y experiencia de la organización que tiene que asumir el de-
sarrollo del proyecto, los costes asociados, el calendario temporal de puesta en
marcha y la especialización de las organizaciones externas en el proyecto.
Finalmente, el proyecto se evalúa en términos de beneficios tangibles e intan-

gibles, y aquí se pueden dar casos en que sea plausible un sobrecoste temporal
o económico para alcanzar beneficios intangibles, normalmente estratégicos,
que la organización requiere. Por ejemplo, mejorar la imagen corporativa con
el uso y la difusión del software libre y la filosofía libre.
2.1.2. Las etapas
El ciclo de vida del proyecto se implementa en forma de etapas sucesivas y,

eventualmente, simultáneas en el tiempo. Cada etapa cumple un objetivo cla-
ro y definido en un escenario relacionado con el proyecto, de tal manera que
el conjunto de etapas cumplan los objetivos del proyecto.
A grandes rasgos, se puede entender una etapa como un proceso que

recibe unas entradas y produce unas determinadas salidas. Es decir, re-
quiere de un escenario previo con información sobre el entorno para
producir unos determinados resultados.
En este sentido, se establece una relación entre las diferentes etapas del pro-
yecto, ya que cada etapa cumple una parte de sus objetivos globales. Normal-
mente, esta relación puede tomar dos formas:
• Dependencia: entre dos etapas determina que una etapa requiere el resul-
tado de la ejecución de la otra para poder cumplir su tarea. Eso implica
que las etapas se tendrán que ejecutar inevitablemente de manera secuen-
cial en el tiempo, en primer lugar la etapa generadora de los resultados y
en segundo lugar la etapa consumidora de los resultados. Por ejemplo, la
etapa de desarrollo requiere del estudio y análisis de los requisitos de la
implantación de sistemas para poder cumplir su tarea.
• Independencia: entre dos etapas determina que dos etapas no tengan una
relación directa ni ningún prerrequisito concreto. Eso implica que las eta-
pas se podrán ejecutar de manera simultánea en el tiempo, aunque es po-
sible que sean necesarios más recursos. Por ejemplo, la etapa de implanta-
ción del sistema podría ejecutarse de manera simultánea con la etapa de
formación de los usuarios.
Por otra parte, las etapas también permiten la ejecución del proyecto de ma-
nera distribuida, es decir, que una o más etapas sean encargadas a diferentes
equipos, ya sean internos o externos a la organización (insourcing y subcon-
tratación).
Los casos extremos se pueden presentar cuando diversas etapas se adjudican

a organizaciones externas diferentes. Todo dependerá de las características del
proyecto, de la especialización de las organizaciones externas y de los costes
asociados.
(6)
Como consecuencia de los anteriores párrafos, se pone de relieve la importan- En inglés, deliverables.
6
cia de los entregables entre etapas. La importancia de documentar los resul-
tados en forma de entregables es triple:
• Porque la documentación de la etapa sintetiza el desarrollo y los resulta-

dos.
• Porque el resultado de la etapa es importante para las etapas que dependen

de ella.
• Porque el resultado de la etapa constituye un resultado evaluable del de-

sarrollo del proyecto.
Las connotaciones de ejecución interna o externa de cada etapa enfatizan la

importancia de los entregables. También hay que constatar que su importancia
es proporcional a la complejidad y el tamaño del proyecto.
2.1.3. La ejecución
La ejecución del proyecto se iniciará según la planificación inicial propuesta

y siempre con el estricto seguimiento de la organización que es objeto de la
implantación del sistema. Globalmente, se puede destacar el seguimiento de
tres parámetros principales:
• Tiempo. El control y gestión del tiempo es fundamental para el seguimien-

to del proyecto, ya que cualquier ajuste sobre este parámetro tiene con-
secuencias económicas directas. También es de especial importancia para
el encadenamiento de las etapas, especialmente si éstas están asignadas a
equipos diferentes.
• Subcontratación. El control de la subcontratación de las etapas, o even-

tualmente de todo el proyecto, es importante con el fin de garantizar la
adecuación del trabajo y sus resultados a los objetivos del proyecto y de la
organización. Es importante poner de relieve el seguimiento y calidad de
los entregables y el correcto seguimiento del calendario temporal.
• Calidad. El control de la calidad de las tareas que se cumplen en la ejecu-

ción del proyecto es fundamental para la calidad final de la implantación.
También tiene que ser cualitativa la comunicación y la transmisión de in-
formación entre el equipo que desarrolla el proyecto y la organización,
con objetivos de eficiencia y eficacia.
En la práctica, la ejecución de las etapas se puede ver retardada por motivos

diversos, ajenos o no al proyecto y su gestión. Por ejemplo, el decalaje en la
llegada del material necesario, la baja de analistas o programadores durante un
periodo o la complejidad de un desarrollo que no se había previsto de manera
inicial. Los retrasos acostumbran a tener una contrapartida económica.
Cuando se produce un retraso, se pueden generar dos tipos de decisiones:

• Por una parte, se puede asumir el retraso en la ejecución de la etapa, de

forma que se concluya y acepte el retraso de todas las etapas que dependen
de ella y, consiguientemente, del proyecto en general.
• Por otra parte, se puede concluir que el retraso del proyecto no es asumible
y se decide dedicar más recursos a una o más etapas para mantener la ca-
dencia temporal. Sin embargo, en algunas ocasiones asignar más recursos
no implica una mejora productiva proporcional a la asignación.
En general, los retrasos no tendrían que afectar directamente a las etapas que
se ejecutan de manera simultánea a la etapa que ha sufrido un retraso. Sin
embargo, eventualmente puede resultar adecuado valorar un reajuste tempo-
ral teniendo en cuenta el retraso experimentado en las otras etapas.
Por ejemplo, si la implantación del sistema ha sufrido un retraso a causa de un

retraso excesivo en la recepción de los materiales, se puede plantear retrasar
voluntariamente la fase de formación de los usuarios con el objetivo de ajus-
tarla al momento de la implantación. De esta manera, se evitaría el decalaje
entre la formación de los usuarios y la aplicación de los conocimientos sobre
el nuevo sistema implantado.
2.1.4. Los resultados
Los resultados del ciclo de vida de un proyecto deben tener una relación
directa con los objetivos estratégicos del proyecto y de la organización.
El ciclo de vida en sí mismo sólo representa una forma metódica y rigu-
rosa de abordar la resolución de una problemática concreta, al dividir
la complejidad inherente al proyecto en diversas etapas.
En cierta manera, el ciclo de vida constituye una forma adecuada de reducir

el riesgo global del proyecto. La ejecución de las etapas, en forma de refina-
mientos sucesivos con el fin de solucionar la problemática, contribuye a la
adaptación y solución progresiva de problemas que pueden resultar de una
complejidad elevada.
Hay que valorar la importancia del equipo de gestión del proyecto, que con
su tarea de planificación y coordinación colabora a que el proyecto se lleve a
cabo con bastantes garantías de éxito. La gestión es una tarea dinámica en el
tiempo y tiene que ayudar a reajustar las diferencias que se producen entre la
planificación y la realidad a lo largo de la ejecución del proyecto.
En general, los resultados de un proyecto de implantación de sistemas se pue-

den englobar en los siguientes aspectos:
• Organización. Para la organización, el proyecto tiene que responder a las

expectativas de la actuación estratégica de la cual surge. Es de especial im-
portancia poner de relieve el funcionamiento cualitativo del sistema, su
integración en la metodología de la organización, la adaptación de los
usuarios y la mejora competitiva de la organización.
• Sistema. El sistema tiene que cumplir con todos los objetivos y expecta-
tivas de la organización y tiene que responder de manera operativa a los
objetivos de la actuación estratégica de la organización. El cumplimiento
de los objetivos tiene que ser cualitativo en términos de eficiencia y efi-
cacia funcional, tanto del propio sistema como de su interacción con los
usuarios directos e indirectos.
• Usuarios. El sistema tiene el objetivo de dar soporte tecnológico al funcio-

namiento de la organización a través de sus usuarios. La importancia de
la inclusión de los usuarios en el proyecto de implantación es estratégica,
ya que sin su participación en el proceso y su aceptación del sistema, la
implantación puede resultar problemática o inviable, a más de tener re-
percusiones económicas.
• Documentación. Como en todo proyecto, la documentación es un aspec-

to fundamental para la calidad del sistema implantado, para su integración
actual y evolución futura. Desde los documentos entregables entre etapas
hasta la documentación final o los manuales de usuario, todos estos ma-
teriales cumplen una tarea importante para el mantenimiento y soporte
del sistema.
• Soporte. El sistema debe tener un equipo de soporte desde el inicio del

proyecto, y especialmente en las etapas de desarrollo, implantación y for-
mación de los usuarios. El equipo debe permitir garantizar la interacción y
la comunicación de todos los implicados en el proyecto durante y después
de la implantación, bajo la forma de equipo de soporte para la formación
continuada o la resolución de dudas y problemas.
En cualquier caso, un proyecto de implantación de sistemas tiene que permitir

que la organización y sus usuarios evolucionen hacia nuevos retos estratégicos.
La creación de un clima de confianza y aceptación del cambio es fundamental
para la consecución de sus objetivos.
Aceptación del cambio
Normalmente, este proceso se llama gestión�del�cambio y engloba todos aquellos as-

pectos y procedimientos que tienen que permitir gestionar y solucionar las eventuales
problemáticas y reticencias a la implantación de un nuevo sistema en la organización,
especialmente si éste se implementa en software libre.
2.2. Estudio de la situación actual
En este apartado se define el análisis de sistemas y se presentan las principa-

les características y particularidades. Se detallan las diferentes fases que com-
ponen el estudio, los principales factores que influyen en su desarrollo y los
resultados que se espera obtener del análisis.
Ved también
El análisis de sistemas es una investigación principalmente teórica que
tiene que permitir ofrecer una visión clara y precisa del estado del siste- Consultad los apartados sobre
el plan estratégico de la orga-
ma de la organización, en referencia al ámbito del proyecto y de cuya nización y el origen de la im-
plantación de sistemas del pri-
actuación estratégica deriva. mer módulo para conocer más
aspectos de la relación entre el
proyecto de implantación y la
estrategia de la organización.
El análisis de sistemas se concreta en dos aspectos complementarios:
• Parte del análisis se asimila a una aplicación tecnológica del estudio de

un caso, con la evaluación cualitativa del sistema desde el punto de vista
metodológico y procedimental.
El estudio del caso
El estudio del caso es un método científico que permite la exploración en profundidad de

un objeto o circunstancia a través de estrategias empíricas, con el objetivo de comprender
el hecho que se estudia. Normalmente se usa para la exploración inicial y en combina-
ción con otras técnicas, como por ejemplo las técnicas cuantitativas (relacionadas con
la estadística).
• Parte del análisis se asimila al estudio de cumplimiento o competencia

del sistema de la organización, con la evaluación cuantitativa del sistema
desde el punto de vista funcional y tecnológico.
(7)
Las implicaciones teóricas de la investigación ponen de relieve la importancia No sólo es necesario tener en
cuenta el coste económico direc-
de proceder de manera metódica, rigurosa y exhaustiva. Eventuales errores de
to de la dedicación, sino también
apreciación en esta etapa pueden provocar problemas en etapas posteriores, o todos aquéllos que son indirec-
tos, como por ejemplo el coste de
incluso poner en duda la continuación del proyecto a causa de sesgos entre aborto de un proyecto iniciado y
el proyecto, el sistema actual y la estrategia de la organización, con las consi- el coste de oportunidad que se ha
perdido.
guientes repercusiones económicas7.
Aunque en este apartado se presentan las características del estudio inicial li-
gado a un sistema ya implantando, su estructura también puede ser aplicada a
proyectos de nueva implantación, trasladando el objeto de estudio al ámbito
de la organización, al mercado actual e histórico, a las tendencias tecnológicas
futuras y a otros proyectos similares que se hayan emprendido anteriormente.
También hay que indicar que esta primera etapa del proyecto puede no tener
relación directa con el software libre, ya que el objetivo es analizar y evaluar el
sistema implantado o el mercado actual, sea cual sea su forma de implantación
o tendencia, respectivamente.
A grandes rasgos, se pueden considerar tres grandes fases dentro del análisis
de sistemas: la identificación del sistema, la preparación o desarrollo del caso
de estudio y la evaluación final.
2.2.1. Identificación del sistema
La identificación del sistema pretende definir el objeto, el alcance y los obje-

tivos del estudio. La concreción de estos parámetros tiene una relación directa
con la actuación estratégica de la cual deriva el proyecto y tiene que permitir
establecer el escenario de evaluación.
Hay que tener presente que un sistema ya implantado no es únicamente un

conjunto de elementos tecnológicos, sino también un conjunto de funciona-
lidades, métodos y procedimientos con un impacto directo en los usuarios y
en la organización en general.
En este sentido, es importante destacar que el alcance del estudio tiene que
incluir los elementos tecnológicos de la implantación, las funcionalidades que
este sistema cubre actualmente, los procedimientos y métodos de actuación
que se derivan de su interacción con el funcionamiento de la organización
y del impacto sobre el uso que hagan los usuarios directos e indirectos del
sistema.
De estos parámetros es importante determinar dos aspectos principales:
• Por una parte, determinar las diferentes fuentes de información que tienen Ved también
que permitir obtener los datos para el posterior análisis del sistema.
En el apartado siguiente sobre
desarrollo del caso de estudio
• Por otra parte, identificar la naturaleza cuantitativa o cualitativa de los se presentan las principales di-
ferencias entre las técnicas de
datos que se obtendrá de las fuentes de información, ya que las técnicas obtención de fuentes de infor-
mación.
para su obtención difieren de manera sustancial.
Datos cuantitativos y datos cualitativos
Los datos cuantitativos son variables numéricas que cuantifican características o atribu-
tos. Por ejemplo, el número de usuarios activos en el sistema por unidad de tiempo.
Los datos cualitativos son variables que diferencian características o atributos, no los
cuantifican. Por ejemplo, la combinación de colores de la interfaz de usuario de una
aplicación.
El resultado de esta fase es un documento de trabajo en el cual figura el objeto,

el alcance y los objetivos del estudio, así como una relación de datos que es
necesario obtener y la fuente de información asociada.
2.2.2. Desarrollo del caso de estudio
Esta fase centra su actividad en la recopilación de todos los datos importantes

para el estudio que se han detectado en la fase de identificación del sistema.
La recopilación de la información puede ser muy diversa en la práctica: fuentes

documentales históricas, entrevistas en detalle, resultados de auditorías tecno-
lógicas, herramientas de conteo de rendimiento, documentación de proyectos
anteriores, especificaciones tecnológicas, o incluso informes de incidencias.
Es posible que en la recopilación de datos se denoten otros aspectos interesan-

tes pero no considerados en la fase de identificación del sistema. En cualquier
caso, la recogida tiene que ser rigurosa y mantener criterios de estructuración
y organización en su desarrollo.
Sin embargo, se pueden diferenciar dos casos genéricos para la recopilación

de datos:
• Datos�cuantitativos. Normalmente, este tipo de datos se pueden recoger

directamente de soportes tecnológicos. El mismo sistema implantado pue-
de disponer de contadores de rendimiento, transacciones, capacidad, vo-
lumen, etc., de los cuales se pueden obtener resultados estadísticos intere-
santes si se consideran unidades de tiempo o de coste, por ejemplo.
• Datos�cualitativos. Normalmente, este tipo de datos se recogen de docu-

mentación escrita, reuniones o entrevistas al personal. En este caso, es im-
portante destacar el procedimiento de obtención de información a partir
de entrevistas y reuniones, donde su preparación y ejecución minuciosa
permitirá obtener información de calidad.
Hay que denotar la importancia de seguir un proceso metódico que permita

obtener datos tanto cuantitativos como cualitativos, ya que el sistema es una
herramienta de apoyo a las personas y a la organización. Cualquier dato es
importante desde el punto de vista de la evaluación y valoración del sistema.
En esta fase se suele iniciar el desarrollo del inventario de hardware y software, Ved también
así como el diagrama de red del sistema actual. Además de ser útil para deter-
Encontraréis más detalles del
minar el estado actual, puede resultar eficiente y al mismo tiempo planificar inventario de hardware y soft-
una eventual migración del sistema. ware, y de los diagramas de
red en los apartados 2.7.3 y
2.7.4 de este módulo.
El formato final del caso acostumbra a ser un informe de investigación, donde
figuran estructurados, organizados y valorados todos los aspectos que se han
presentado anteriormente. Es importante que el informe justifique los datos y
resultados que presenta, así como relacionarlos entre ellos y con la definición
del proyecto, a la busca de posibles relaciones de dependencia o independen-
cia.
En función del tipo de información que se presente, puede ser útil el uso de
resultados estadísticos, tablas, gráficos o diagramas y, en general, todo aquello
que ayude a la presentación, comprensión y valoración de los datos que se
incluyen en el informe.
(8)
Una de las herramientas más utilizadas para la presentación de resúmenes eje- DAFO son las siglas de debilida-
8 des-amenazas-fortalezas-oportuni-
cutivos es el análisis DAFO , donde se incluyen las principales conclusiones dades. En inglés, SWOT.
del estudio del sistema actual desde el punto de vista estratégico. Eventual-
mente, y si las particularidades del proyecto lo requieren, se pueden presentar
tablas DAFO que clasifiquen las diferentes características del sistema según el
resultado de su evaluación; por ejemplo, si el hardware del sistema actual es
una debilidad del sistema para afrontar la actuación estratégica.
2.2.3. Evaluación final
La evaluación final del análisis del sistema es el primer punto de control del
proyecto, y tiene el objetivo de determinar la viabilidad del sistema actual
respecto de las actuaciones estratégicas de la organización y, por lo tanto, de
valorar la necesidad de continuar con el proyecto.
Globalmente, se pueden considerar cuatro grandes grupos de características

que cabe valorar:
• Operativas. Tienen relación con la interacción funcional de los usuarios

con el sistema implantado, la ergonomía, el rendimiento, la eficiencia, la
eficacia o la utilidad.
• Organizacionales. Tienen relación con los procedimientos y métodos que

ha generado el sistema implantado, y con los beneficios e inconvenientes
que producen en la organización.
• Funcionales. Tienen relación con la eficacia y eficiencia de las tareas que

cumple el sistema implantado, la extensión, la fiabilidad, el rendimiento
o los errores de funcionamiento.
• Económicas�y�legales. Tienen relación con el coste del sistema implan-

tado y la regularización legal, como el mantenimiento, las licencias o la
administración del sistema.
La evaluación del sistema puede generar tres grandes grupos de conclusiones:
• El�sistema�es�viable. El estudio y valoración concluye que el sistema ac-

tual está preparado para asumir las actuaciones estratégicas de la organiza-
ción. Normalmente, este tipo de conclusiones se dan en casos donde se ha
emprendido un estudio para conocer el estado de un sistema grande y/o
complejo, del que puede ser difícil valorar la evolución superficialmente.
La evaluación positiva del sistema actual implica la cancelación del pro-
yecto de implantación, ya que no se denotan indicios que requieran una
nueva implantación.
• El�sistema�es�parcialmente�viable. El estudio y valoración concluye que

el sistema actual requiere actualizaciones menores para poder asumir las
actuaciones estratégicas de la organización. Normalmente, los cambios se

centran en la actualización o cambio de un conjunto reducido de elemen-
tos, como por ejemplo el reemplazo de dispositivos o la actualización del
software.
La evaluación parcialmente positiva del sistema actual implica la necesi-
dad de continuar con el proyecto de implantación, aunque será conve-
niente revisar los objetivos y el alcance para adecuarlo a las necesidades
detectadas.
• El�sistema�no�es�viable. El estudio y valoración concluye que el sistema

actual no puede asumir las actuaciones estratégicas de la organización.
Normalmente, este tipo de conclusiones se dan en casos de migración de
sistemas antiguos, que por falta de fiabilidad o rendimiento tienen que ser
totalmente actualizados.
La desfavorable evaluación del sistema actual implica la necesidad de con-
tinuar con el proyecto de implantación de un nuevo sistema. Puede ser
conveniente revisar los objetivos y el alcance del proyecto, ya que la sus-
titución del sistema actual puede requerir más recursos de los previstos al
inicio.
Tanto el informe de análisis como la evaluación final del sistema actual son
presentados a la organización por parte de la comisión de seguimiento del
proyecto. Normalmente, la decisión final sobre la continuación del proyecto
corresponde al órgano director de la organización.
El resultado de esta etapa es doble:
• Por una parte, se obtiene un informe completo del estado actual del sis-
tema, donde se relevan las principales características del sistema desde el
punto de vista de la estrategia de la organización.
• Por otra parte, la decisión de la organización respecto de la continuación

del proyecto, y las eventuales actuaciones que hay que emprender para
adecuar el sistema a la estrategia de la organización.
2.3. Estudio de los requisitos de la implantación
En este apartado se define el estudio de requisitos de la implantación de sis-

temas y se presentan las principales características y particularidades. Se deta-
llan las diferentes fases que componen el estudio, los principales factores que
influyen en su desarrollo, y los resultados que se espera obtener del estudio.
El estudio de los requisitos del sistema es un proceso por el cual se anali-

za de forma metodológica la problemática que necesita ser solucionada.
Los objetivos del estudio de requisitos siguen dos tendencias principales:
• Definición�de�la�implantación. El estudio de requisitos permite concre-

tar de forma exhaustiva todas las características que tiene que tener y per-
mitir el nuevo sistema a implantar. En cierta manera, define los objetivos
concretos y funcionales que tiene que alcanzar la implantación.
• Reducción�del�riesgo. El estudio de requisitos también permite reducir el

riesgo del proyecto y de su gestión, concretando y refinando progresiva-
mente las características de la solución a implantar.
El esfuerzo que normalmente se dedica al estudio de los requisitos de un pro-

yecto de implantación de sistemas es grande, por dos motivos principales:
(9)
• Por una parte, porque puede resultar difícil concretar y estructurar de for- Un error cometido en las etapas
de diseño del sistema, que sea de-
ma metodológica las ideas y esperanzas que tienen los usuarios y respon-
tectado y solucionado en las eta-
sables de la organización sobre el nuevo sistema, teniendo en cuenta que pas de desarrollo, puede llegar a
tener una relación de coste de uno
los requisitos de usuario pueden evolucionar con el tiempo. a diez.
• Por otra parte, porque es importante para el desarrollo posterior del pro-
yecto, ya que cualquier error de apreciación cometido en esta fase y detec-
tado en etapas posteriores tiene repercusiones económicas y temporales
sobre el proyecto o costes adicionales no previstos, que pueden poner en
peligro la consecución del proyecto9.
Un requisito o requerimiento es una característica que tiene que cum-

plir el nuevo sistema. Es decir, un atributo que tiene que permitir al sis-
tema alcanzar los objetivos fijados. El formato de los requerimientos es
habitualmente textual, pero también se pueden presentar en forma de
tablas y diagramas, si ayudan a clarificar y especificar su objetivo.
De forma general, se pueden definir cuatro tipos de requisitos diferentes:
• Política�estratégica. Los requisitos ligados a la política estratégica de la

organización se centran en aspectos generales del proyecto, de su gestión,
de su resultado, o de la tendencia que tiene que seguir. Por ejemplo, la
imagen y la ética corporativa, o las características históricas propias a la
organización.
• Métodos�y�procedimientos. Normalmente, la implantación de un nuevo

sistema es un buen momento para actualizar y mejorar los métodos y pro-
cesos de la organización y/o del sistema. Además de revisar de forma ex-

haustiva los actuales procedimientos, también habrá que tener en cuenta
la especificación de los futuros métodos y procedimientos derivados de
los nuevos objetivos o funcionalidades que tendrá que cumplir el nuevo
sistema.
• Funcionamiento�del�sistema. Los requisitos de funcionamiento del siste-

ma son derivados de la interacción de los usuarios con el sistema. Hay que
diferenciar los requisitos funcionales de los no funcionales: los funciona-
les corresponden a acciones específicas que el sistema tendrá que poder
ejecutar, mientras que los no funcionales corresponden a limitaciones o
restricciones al mismo tiempo que ejecutar acciones, y permiten enlazar
las acciones con los métodos y procedimientos.
• Factores�clave�y�prioridades. La mayoría de sistemas tienen un determi-

nado número de elementos principales, en cierta manera, forman parte
del núcleo del sistema. En una nueva implantación, se puede dar prioridad
o preferencia a aquellos componentes que se consideran indispensables
para el funcionamiento del sistema y de la organización, así como otros
componentes que no la tienen pueden ser considerados con una prioridad
más baja..
También hay que denotar que la etapa de recogida de requisitos no tiene una
relación directa con el software libre, ya que la implantación de sistemas en
software libre tiene que cumplir los mismos requisitos y objetivos que cual-
quier otro tipo de implantación.
A grandes rasgos, se pueden considerar cinco grandes fases para el estudio de

los requerimientos de un sistema: la identificación y definición, la especifica-
ción y estructuración, la verificación, la validación, y la evaluación final.
2.3.1. Identificación y definición
Esta primera fase del estudio de requerimientos pretende identificar y definir Ved también
la problemática que se tiene que resolver y la tipología del proyecto, así como
Consultad el apartado 1.2 del
determinar las principales fuentes de información para la recogida de datos. primer módulo para conocer
los diferentes tipos de proyec-
tos de implantación de siste-
La etapa de estudio de requisitos parte de la información documental de la mas.
etapa de análisis del estado actual, de tal forma que parte de la tarea de iden-
tificación de la problemática ya está concretada previamente.
Hay que identificar dentro de la organización a los implicados directos e indi-

rectos, y definir el alcance de la problemática dentro de la organización, los
implicados directos e indirectos, ya sean humanos, materiales, funcionales,
organizacionales, procedimentales o tecnológicos. Normalmente, todos estos
elementos permitirán recuperar información fundamental para la definición
del nuevo sistema que, conjuntamente con el informe del estado actual, per-
mitirán establecer un corpus de conocimiento adecuado para la toma de de-
cisiones.
También es importante destacar el rol que juega la tendencia del mercado ac-
tual en la definición de requisitos. Conocer las particularidades de sistemas si-
milares, organizaciones del mismo sector, últimas innovaciones o tendencias
futuras en la temática del proyecto, pueden ser de gran ayuda para concretar,
proponer, evaluar y comprender las peticiones de los usuarios y responsables
de la organización.
El resultado de esta primera fase suele representarse en un documento de tra-

bajo con la definición exhaustiva del objetivo y el alcance del proyecto, una
relación de elementos a considerar, fuentes de información interna a la orga-
nización, y una relación de elementos o tendencias de mercado susceptibles
de contener información relevante para el proyecto.
2.3.2. Especificación y estructuración
La fase de especificación y estructuración pretende recoger los datos relevantes

de todos los elementos identificados anteriormente, y organizarlos bajo crite-
rios metodológicos que permitan crear un corpus de conocimiento riguroso
que represente adecuadamente la realidad.
Esta fase parte del documento de trabajo elaborado en la fase anterior, con una
primera aproximación a los elementos y fuentes de información susceptibles
de contener información relevante para el proyecto. Sin embargo, el desarro-
llo práctico del estudio puede llevar a considerar nuevas fuentes de informa-
ción y nuevos aspectos relevantes para el proyecto, que no se habían tenido
en cuenta en la fase anterior. Es importante investigar todos los detalles que
puedan surgir en la medida en que lo permitan los plazos establecidos.
Se pueden identificar dos tareas dentro del desarrollo de esta fase:
• Recolección� y� especificación. Trata de resolver las funcionalidades del

sistema. Es decir, qué hace falta que el sistema haga, no cómo lo tiene
que hacer. Algunas fuentes de información tienen tendencia a centrarse
en cómo realizar las acciones en lugar de determinar las particularidades
de la tarea en sí misma.
• Estructuración�y�organización. Trata de organizar los datos de forma me-

tódica y comprensible. Es importante destacar que puede ser conveniente
priorizar algunos requisitos antes que otros, en consonancia con los ele-
mentos del sistema que son indispensables para su funcionamiento.
De la misma forma que en el estudio de la situación actual, la recolección de

los datos puede responder a criterios cuantitativos o cualitativos:
• Datos�cuantitativos. Provienen normalmente de soportes tecnológicos, y

permiten el tratamiento masivo para obtener resultados estadísticos que
permitan por una parte verificar y justificar los datos cualitativos, y por la
otra, modelar y extrapolar resultados hacia nuevas funcionalidades.
• Datos� cualitativos. Provienen normalmente de entrevistas y reuniones

con los implicados, y permiten obtener resultados funcionales y no fun-
cionales respecto del sistema, así como los procedimientos y los métodos
que se ven afectados por el proyecto.
Los requisitos de implantación de sistemas se relacionan con los elementos

básicos de todo sistema, como por ejemplo el hardware, el software, la infraes-
tructura, el personal, los procedimientos, las funcionalidades, o incluso los
idiomas, la documentación, los formatos y los estándares.
El formato de presentación de los requisitos acostumbra a ser textual, orga-

nizados según las características del proyecto, del sistema y de las particulari-
dades de los mismos requisitos. También se pueden utilizar tablas, gráficos o
diagramas con el objetivo de mejorar la definición, el razonamiento y la apre-
ciación de los conceptos que se presentan.
El resultado de esta fase suele representarse en un documento de trabajo con la

presentación de todos los requisitos organizados, estructurados y justificados
de acuerdo con el ideario del proyecto. La precisión y claridad de este docu-
mento es fundamental para todo el proyecto, ya que no sólo depende todo
el desarrollo posterior del mismo, sino también la aceptación por parte de la
organización de los términos de la implantación final.
2.3.3. Verificación
La fase de verificación de los requisitos pretende evaluar los requisitos recogi-

dos y especificados en las fases anteriores, y valorarlos respecto de la coheren-
cia como sistema y con las pretensiones de la organización.
Esta fase parte del documento de trabajo de la anterior fase, que recoge de
forma organizada y metódica los requisitos obtenidos en el estudio.
La verificación formal de los requisitos se compone de dos grandes procesos:
• Análisis�tecnológico. El análisis tecnológico de los requisitos es un pro-

ceso que pretende analizar y concluir que todos los requisitos recogidos
son complementarios y que forman un sistema lógico, razonable y viable
de ser implantado.
En esta fase se suelen detectar requisitos antagónicos, fruto de las diversas

fuentes de recogida de información. El conflicto se puede resolver consul-
tando las otras características recogidas en los requisitos y/o validando las
opciones con los implicados directos o con la organización.
• Análisis�funcional. El análisis funcional de los requisitos es un proceso

que pretende analizar y concluir que el sistema que se deriva de la imple-
mentación de los requisitos responde a los requisitos y objetivos del pro-
yecto y de la organización.
En esta fase se pueden detectar asunciones erróneas en los requisitos, que
pueden ser antagónicas respecto de los objetivos del proyecto. El conflicto
se puede resolver con la revisión y consulta de los aspectos problemáticos
con los implicados directos y/o con la organización.
El proceso de verificación de los requisitos es eminentemente tecnológico y

metodológico, cuestionando la coherencia y viabilidad de la eventual imple-
mentación e implantación del sistema que se define en los requisitos.
Eventualmente, puede ser interesante la participación de diversas personas en

la revisión de los requisitos. Los diferentes puntos de vista pueden ayudar a
identificar y solucionar los posibles errores o carencias de forma más efectiva.
De la revisión también pueden surgir nuevas cuestiones o situaciones que no

se habían planteado hasta el momento, lo que puede inducir a un bucle en-
tre la recogida de requisitos y su verificación, hasta que haya convergencia
y coherencia en los resultados (proceso parecido a la metodología por refina-
mientos sucesivos).
Metodología top-down
La metodología top-down, o por refinamientos sucesivos, parte de la definición general

de la problemática y realiza un bucle especificando y desglosando cada elemento hasta
que se considera un nivel de detalle suficiente y adecuado. Normalmente, el resultado se
puede expresar en forma de árbol de procesos.
El resultado de esta fase es una actualización del documento de trabajo con

los requisitos, ya creado en la fase anterior. La actualización ha permitido la
revisión en detalle de los conceptos de la implantación, además de identificar
y resolver los posibles errores que podían existir en la relación de requisitos
inicial.
2.3.4. Validación
La fase de validación de los requisitos pretende acordar los requisitos de la

implantación del nuevo sistema –fruto del estudio llevado a cabo– con la or-
ganización. El acuerdo de los requisitos es la herramienta fundamental para la
formalización contractual de la implantación del sistema.
Esta fase requiere la participación activa de la organización, que tiene que ana-
lizar en profundidad la propuesta de requisitos que resulta de las anteriores
fases. Hay que denotar la importancia de la transmisión de información entre
ambos colectivos, ya que las características de la implantación del sistema de-
penden de la comprensión del estudio de requisitos.
Eventualmente, el documento de trabajo interno que recoge los requisitos pue-

de no ser totalmente adecuado para ser presentado al comité de seguimiento
del proyecto. En estos casos, puede ser necesario crear otros documentos o
presentaciones que permitan transmitir la misma información de forma más
clara, efectiva y gráfica.
El proceso de validación de los requisitos por parte de la organización puede

concluir en nuevas revisiones de los requisitos. Normalmente, estas nuevas
revisiones o refinamientos tienen relación con la adición de funcionalidades
al sistema por parte de la organización, no previstas en el proyecto de forma
inicial.
Sin embargo, estas revisiones no pueden sucederse indefinidamente, ya que

pueden afectar directamente a la viabilidad del proyecto y al calendario de la
implantación, además de las implicaciones económicas que pueden tener en
el aumento de los requisitos que hay que implementar.
El resultado de esta fase tiene una estrecha relación con la fase de evaluación
final del estudio de requisitos del sistema. Normalmente, de la fase surge la
última revisión del documento de trabajo con los requisitos del nuevo sistema,
acordada y validada por la organización y el equipo que ha realizado el estudio
de requisitos.
La evaluación final del estudio de requisitos es el segundo punto de control

del proyecto, y tiene el objetivo de determinar la viabilidad del proyecto de
implantación a partir de los requisitos del nuevo sistema y, por lo tanto, de la
necesidad de continuar con el proyecto.
Esta fase tiene una estrecha relación con la validación de los requisitos, ya que
el principal documento de trabajo es la última definición de los requisitos de
la implantación del sistema, acordada por la organización. Eventualmente, las
fases de validación y de evaluación final se pueden fusionar desde un punto
de vista decisorio sobre la continuación del proyecto.
La viabilidad de los requisitos del sistema se evalúa considerando su adecua-

ción respecto del sistema actual, la organización, y la actuación estratégica
que ha iniciado el proyecto. Con el estudio de requisitos se plasma la primera
aproximación formal al nuevo sistema y las primeras apreciaciones sobre el
volumen y el coste de los cambios.
En cierta manera, la evaluación de los requisitos se asimila a la evaluación del

estado actual, presentada en el primer apartado, donde se evalúa en términos
de economía, tecnología, funcionalidad y legalidad. Sin embargo, también se
pueden valorar otros aspectos relacionados con la estrategia de la organiza-
ción, como por ejemplo la capacidad de evolución de la organización, los be-
neficios intangibles del cambio, la calidad de la gestión o la ética corporativa.
La evaluación de la propuesta de requisitos del nuevo sistema puede generar

tres grandes grupos de conclusiones:
• El�proyecto�no�es�viable. La valoración de los requisitos del nuevo siste-

ma por parte de la organización concluye que la implantación del nuevo
sistema no es viable y el proyecto se aborta.
Los motivos para llegar a esta conclusión pueden ser diversos, e incluso,
externos al mismo proyecto. Normalmente, esta resolución puede tener
relación con la economía, la financiación, la competencia o el abandono
de la estrategia que ha iniciado este proyecto.
(10)
• El�proyecto�es�viable�parcialmente. La valoración de los requisitos del Algunas organizaciones prefie-
ren repartir la carga de inversión
nuevo sistema por parte de la organización concluye que el proyecto se
que supone una nueva implanta-
llevará a cabo de forma parcial, donde sólo algunos elementos del nuevo ción en diferentes años contables.
sistema serán implantados.

Normalmente, esta resolución puede tener relación con la economía y la
financiación. Hay que tener en cuenta que, en algunos casos, la implanta-
ción parcial se puede realizar de forma progresiva o por etapas10. En estos
casos, es importante establecer garantías de cohesión entre las diferentes
implantaciones a lo largo del tiempo.
• El�proyecto�es�viable. La valoración de los requisitos del nuevo sistema

por parte de la organización es favorable y el proyecto continúa sin limi-
taciones o restricciones importantes que afecten a la definición principal
del proyecto.
• Por una parte, se obtiene un informe completo de los requisitos del nuevo
sistema a implantar validado por el equipo y la organización.
• Por otra parte, la decisión de la organización respecto de la continuación

del proyecto y sobre el alcance de implantación del nuevo sistema.
2.4. Análisis de las soluciones en software libre
En este apartado se define el análisis de las soluciones al proyecto de implan-

tación y se presentan sus principales características y particularidades. Se de-
tallan las diferentes fases que componen el análisis, los factores que influyen
en su desarrollo, y los resultados que se espera obtener de la etapa.
El análisis de soluciones es un proceso donde se analiza de forma me-

tódica y rigurosa las diferentes opciones tecnológicas disponibles según
los requisitos del proyecto.
Los objetivos de este análisis se centran principalmente en tres aspectos com-

plementarios:
• Conocimiento� del� mercado. El análisis de soluciones permite estudiar

y evaluar la situación del mercado actual en referencia a la definición,
el alcance y los objetivos del proyecto de implantación. La variedad de
soluciones actuales motiva un análisis en detalle y escrupuloso.
• Adecuación�de�la�solución. El análisis permite seleccionar las soluciones

que mejor se adaptan a la problemática del proyecto y a la implantación
del sistema. Además, las propiedades de apertura del código fuente inhe-
rentes al software libre permiten el ajuste y adecuación final de las solu-
ciones seleccionadas en forma de productos derivados.
• Reducción�del�riesgo. El análisis de soluciones permite reducir el riesgo

del proyecto y de la implantación del sistema, ya que el estudio permite
adecuar la solución y controlar las principales repercusiones de su implan-
tación.
La etapa de análisis de soluciones en software libre se enmarca en un escenario

delimitado fundamentalmente por dos condiciones:
• Tipología�del�proyecto. La tipología del proyecto, las características y el

ámbito del sistema a implantar determinarán el espectro de busca y el aná-
lisis de soluciones posibles, así como la viabilidad de las diferentes pro-
puestas.
• Análisis�de�requisitos. El análisis de los requisitos del sistema tiene que

determinar el comportamiento funcional y operativo de la solución hacia
los objetivos del proyecto.
Tal como se desprende de los anteriores párrafos, esta etapa parte de los do-
cumentos de definición, objetivos y alcance del proyecto, así como de los re-
quisitos del sistema acordados con la organización. También puede resultar
interesante el informe de evaluación de la situación actual, donde se reflejarán
las características, particularidades y conclusiones de la viabilidad del actual
sistema. Todos ellos tienen que ayudar a centrar y focalizar las características
del análisis.
Esta etapa se fundamenta en la fortaleza y diversificación de la oferta en soft-

ware libre del mercado actual. La busca y selección de soluciones libres que
cumplan los requisitos de la implantación es básica para el proyecto de im-
plantación. En este sentido, el análisis tiene que reflejar las cualidades compe-
titivas del software libre respeto soluciones privativas, considerando especial-
mente las libertades de uso y adecuación del código fuente.
A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa

de análisis de las soluciones en software libre: la búsqueda de las soluciones,
el análisis y valoración de los candidatos, y la evaluación final.
2.4.1. Búsqueda de las soluciones
Esta primera fase de búsqueda pretende identificar soluciones plausibles de

ser implantadas en el marco del proyecto. Se trata de realizar una primera
selección de sistemas cuyo objetivo se aproxime a los objetivos del proyecto.
El software libre constituye una opción válida y viable para la implantación

de sistemas, permitiendo un amplio abanico de libertades sobre el uso, la ex-
plotación, el acceso y modificación al código fuente, y el licenciamiento de
los derivados.
Estas características no sólo permiten su uso libre en organizaciones y parti-

culares, sino también permiten la independencia de los proveedores propie-
tarios, el ahorro en licencias y royalties, aprender del código fuente original,
controlar la obsolescencia con garantías de mantenimiento, calidad y fiabili-
dad del producto, o garantizar aspectos de seguridad, privacidad, interopera-
bilidad y convergencia del software.
Históricamente, se pueden destacar dos ámbitos principales en la implanta-

ción del software libre:
(11)
• Implantación en servicios de infraestructura
11
Por ejemplo, los servidores de
una red local forman parte de los
Desde sus inicios, el software libre ha tenido una relación muy estrecha servicios de infraestructura básica
con la arquitectura de sistemas y los servicios de red. Actualmente, lidera de la organización.
sobradamente algunos sectores12 ante el software propietario.
• Implantación en clientes o usuarios domésticos

13
(12)
Con el paso del tiempo, y gracias a iniciativas de diferente orden, el soft- Por ejemplo, la implantación de
Apache Web Server en servidores
ware libre se ha extendido hacia el entorno de usuario final, habiendo
web es superior respecto de otros
iniciado una nueva trayectoria ante los estándares de facto en el entorno entornos.
doméstico.
(13)
Por ejemplo, la distribución
Ubuntu compete directamente
contra el sistema operativos de Mi-
crosoft, rompiendo muchos mitos
sobre la dificultad de la instalación,
la gestión o el uso de los entornos
GNU/Linux.
(14)
Con todo ello, el mercado actual dispone de una amplia variedad de sistemas Por ejemplo, la distribución
Ubuntu (www.ubuntu.com), la
en software libre en campos muy diversos. La mayoría de proyectos importan-
suite ofimàtica OpenOffice.org
tes disponen de portales en Internet, que permiten el conocimiento, la difu- (www.openoffice.org) o la
14
suite de navegación Mozilla
sión, la descarga y la colaboración con el proyecto . (www.mozilla.org).
(15)
Sin embargo, también existen depósitos públicos15 que permiten la creación, el Por ejemplo, SourceForge.net
(sourceforge.net).
desarrollo y la colaboración en nuevos proyectos relacionados con el software
libre, así como la descarga de los productos resultantes. Los depósitos actúan
en muchos casos de plataforma de lanzamiento para proyectos comunitarios.
Hay que considerar que es posible que no exista una solución única para el
proyecto de implantación, ya sea por alcance o por especialización de los ob-
jetivos. En estos casos, hay que categorizar la busca de soluciones en tipologías
más genéricas, de tal modo que diversos sistemas especializados puedan coo-
perar para dar una solución conjunta a los requisitos del proyecto16.
(16)
Por ejemplo, si se busca una solución para la gestión de una base de datos vía web,
puede resultar factible buscar separadamente un sistema operativo, un servidor web, un
gestor de bases de datos y una herramienta de programación que puedan cooperar para
ofrecer las funcionalidades exigidas. Éste es el caso del entorno LAMP (Linux, Apache,
MySQL i PHP), de gran difusión actualmente.
De la búsqueda de soluciones se tiene que obtener un documento con los re-

sultados de la investigación. Este documento tendría que contener los siguien-
tes aspectos:
• Definición�e�identificación�de�la�búsqueda�de�soluciones. Establece las

características que han guiado la búsqueda, denotando la relación con la
definición del proyecto, objetivos y alcance, así como con la definición de
los requisitos que se han acordado.
• Lista� de� soluciones. El documento tiene que contener una lista de las
soluciones encontradas en el proceso de búsqueda, estableciendo en cada
caso una breve definición de la solución y la relación con los objetivos del
proyecto.
• Ficha�técnica�de�soluciones. La ficha técnica de cada solución tiene que

permitir conocer las principales características del sistema, como por ejem-
plo la definición del proyecto, los depósitos donde se encuentra, el segui-
miento y mantenimiento del producto, los idiomas que soporta, la cola-

boración comunitaria, la licencia final y otros requisitos inherentes al pro-
ducto, como la ergonomía de uso, los requisitos de ejecución y las princi-
pales funcionalidades.
En caso de que no existan soluciones únicas para la problemática que presen-

ta el proyecto y sea necesario la categorización en diferentes soluciones indi-
viduales, el documento se podrá estructurar en categorías por tipología (por
ejemplo, sistemas operativos o suites de ofimática) o por función (por ejemplo,
un servidor de base de datos con interfaz web de acceso y programación).
En algunos casos, se presenta de forma adicional una tabla DAFO para cada una
de las opciones localizadas. Esta tabla tiene especial relevancia en las reuniones
y decisiones ejecutivas, y su objetivo es identificar y sintetizar las principales
características, ventajas e inconvenientes inherentes a su adopción.
2.4.2. Análisis y valoración de los candidatos
La fase de análisis y valoración de los candidatos pretende identificar las so-

luciones más adecuadas al proyecto y a la organización, pero también a las
particularidades del desarrollo, la implantación y la migración.
Esta fase parte del documento de la fase anterior, en el cual se listan las solu-
ciones actuales más indicadas para el proyecto y se detallan las principales ca-
racterísticas. Se trata de seleccionar de manera metódica y rigurosa a los mejo-
res candidatos para la implantación de entre las diferentes alternativas iden-
tificadas.
Normalmente, se analiza, se pondera y se evalúa un conjunto determinado

de parámetros tecnológicos relacionados directamente con el proyecto, la or-
ganización y el proceso de implantación. La valoración individual llevará a
establecer una clasificación ordenada que determinará la adecuación de cada
solución al proyecto de implantación.
De manera general, se pueden considerar los siguientes parámetros para la

evaluación y valoración de una solución:
• Proyecto�y�organización. Hay que valorar la adecuación a los objetivos

del proyecto, la organización, la definición de los métodos y procedimien-
tos, la ética y estándares históricos de la organización y la actuación estra-
tégica que ha emprendido el proyecto.
• Sistema�e�interoperabilidad. Hay que valorar la adecuación a las necesi-

dades del sistema y que garantice el funcionamiento con la dotación de
recursos de hardware, software y red actual o futura, la factibilidad de los
métodos y procedimientos, la implementación de la actuación estratégica,
la interoperabilidad con otros sistemas existentes y estándares de la orga-

nización y las posibilidades de ampliación y evolución futura.
• Funcionalidad�y�ergonomía. Hay que valorar la adecuación a las nece-

sidades funcionales y operativas del proyecto y de la organización y que
garantice la ergonomía de su utilización, implemente los métodos y pro-
cedimientos con garantías de funcionamiento y responda a las esperanzas
de los usuarios y de la organización.
• Eficiencia� y� rendimiento. Hay que valorar que garantice un funciona-

miento eficiente en todo momento, el aprovechamiento y el rendimiento
de los recursos dedicados y el mantenimiento de un equilibrio adecuado
entre recursos y rendimiento a lo largo del tiempo, que permita la evolu-
ción.
• Eficacia�y�fiabilidad. Hay que valorar que garantice el cumplimiento de

las funciones establecidas en los objetivos del proyecto, que mantenga el
cumplimiento funcional de los objetivos en todo momento, que manten-
ga también el equilibrio entre recursos y el cumplimiento a lo largo del
tiempo y que permita la evolución.
• Implantación�y�migración. Hace falta valorar la adecuación al proceso

de implantación del sistema y que permita la migración eficiente y eficaz
a partir de un sistema anterior, minimice las consecuencias de impacto en
el funcionamiento habitual de la organización y garantice herramientas
de soporte, formación y adaptación de los usuarios y de los otros sistemas
existentes.
• Mantenimiento�y�gestión. Hay que valorar que garantice que el sistema

disponga de herramientas de gestión y configuración adecuadas a los ob-
jetivos del proyecto, minimice las operaciones de mantenimiento físicas
y lógicas, garantice el equilibrio entre funcionamiento y mantenimiento
a lo largo del tiempo, y permita la evolución.
• Soporte�y�compromiso. Hay que valorar que garantice el soporte y segui-

miento de sus creadores con el sistema y con sus usuarios y que ayude al
compromiso de la comunidad en la evolución y mejora futura y, en ge-
neral, a todos aquellos aspectos que puedan suponer la obsolescencia del
sistema y la resolución de problemas.
• Licencias. Hay que valorar que garantice el cumplimiento de la legalidad

vigente, establezca el escenario de uso y explotación, permita la distinción
clara y efectiva de las actuaciones que se pueden llevar a cabo con el siste-
ma y especifique las licencias de los eventuales productos derivados.
• Economía. Hay que valorar la adecuación a la economía de la organiza-

ción, a la financiación prevista del proyecto, a los costes de gestión, man-
tenimiento y funcionamiento eficiente y eficaz a lo largo de la vida pre-

vista del sistema y también a los costes de formación y educación de los
usuarios del sistema.
Tal como se desprende de la lista anterior, los parámetros buscan la valoración

de los candidatos en diferentes ámbitos (tecnológico, estratégico, operativo,
económico, etc.), con el objetivo de profundizar, analizar y valorar el impacto
de la eventual implantación en la organización.
El resultado de esta fase es un documento que clasifica y pondera de manera

numérica los diferentes candidatos (eventualmente por categorías) y ordena
las soluciones por grado de adecuación al proyecto y a la organización.
Sin embargo, es posible que se produzcan empates técnicos entre diferentes

soluciones, es decir, que haga falta un estudio adicional entre alternativas que,
a pesar de diferir en sus características, presentan adecuaciones similares para
el proyecto. En estos casos, puede ser útil implementar una tabla DAFO de
cada solución, con el objetivo de hacer surgir diferencias que puedan ayudar
a la elección final.
La evaluación final del análisis de soluciones en software libre es el tercer pun-

to de control del proyecto y tiene el objetivo de determinar el desarrollo del
proyecto de implantación, es decir, la forma que tomará el proyecto y su im-
plementación final.
Esta fase parte de los documentos de la fase anterior, que contienen una clasi-
ficación de las soluciones existentes según su adecuación al proyecto, así como
las fichas técnicas y/o tablas DAFO que las analizan en profundidad.
Esta fase trata de cumplir dos objetivos principales:
• Selección�final�de�candidatos. Aunque la fase anterior ya propone indi-

rectamente las soluciones más adaptadas al proyecto y a la implantación
(mediante la puntuación y la clasificación), puede convenir evaluar adi-
cionalmente la integración global de todas las soluciones.
• Desarrollo�del�proyecto. La selección de las soluciones que satisfacen los

requisitos del proyecto comportarán consecuencias directas en su desarro-
llo, por ejemplo en su coste temporal y económico.
Es importante destacar que los componentes del sistema no estarán desaco-

plados entre sí, por lo que se deberán hallar las mejores soluciones que gene-
ren un sistema estable y operativo, además de cumplir con los requisitos del
proyecto.
(17)
En algunos casos, puede resultar útil realizar pruebas de integración que per- Por ejemplo, si el conector de
los dos sistemas no es eficiente o
mitan determinar la calidad y rendimiento de la cohesión de los diferentes
está limitado por la compatibilidad
elementos, ya que la integración de diversas soluciones altamente puntuadas con otros sistemas.
en sus respectivas categorías no garantiza que el comportamiento global esté

al mismo nivel17.
Con respecto al desarrollo del proyecto, la elección de las soluciones comporta

ajustes en el proyecto, especialmente en la fase de desarrollo. Globalmente, se
pueden considerar tres tipos diferentes de implantación:
• Implantación�directa. Las soluciones que más se ajustan a las necesidades Soluciones de

del proyecto y de la organización se pueden implantar de manera directa, implantación directa
ya sea porque son de uso general o porque los objetivos del proyecto res- Ejemplos de soluciones de im-
ponden a las necesidades específicas de un colectivo grande. plantación directa pueden ser
sistemas operativos, paquetes
En cualquier caso, las diferencias entre los requerimientos del proyecto y de ofimática, clientes de co-
rreo electrónico o navegadores
las funcionalidades de la solución no son determinantes para rechazar la web.
adopción.
• Evolución�de�la�solución. Las soluciones que más se ajustan a los reque-

rimientos del proyecto y de la organización únicamente presentan dife-
rencias significativas en puntos concretos. Su adopción requiere una evo-
lución del código fuente para ajustar las carencias que pueda tener la so-
lución original ante las incidencias del sistema.
Gracias a las libertades que ofrece el software libre, ésta es una opción vá-
lida y viable en la práctica, mientras que la alternativa en software propie-
tario posiblemente requiriría un desarrollo completamente nuevo, con las
implicaciones económicas que ello comporta.
• Desarrollo�nuevo. No existen soluciones que se ajusten con suficiencia a

las incidencias del proyecto y de la organización, por lo que será necesario
un desarrollo completamente nuevo con el fin de solucionar la problemá-
tica.
Estos casos se pueden dar en sistemas con requerimientos muy especializa-
dos, como la robótica. En casos extremos, es posible que tampoco existan
soluciones de propiedad en los canales habituales de comercialización.
En cualquier caso, la libertad de estudiar, analizar y reutilizar el código
fuente del software libre permite mejorar la calidad, eficiencia y eficacia
del nuevo desarrollo y abaratar los costes asociados.
La evaluación de las soluciones en software libre puede conducir a tres grandes

tipos de conclusiones:
(18)
• Proyecto�viable�de�implantación�directa. El proyecto es viable y los re- Por ejemplo, la sustitución
del software MS Word por
quisitos de la implantación se pueden resolver con soluciones existentes.
OpenOffice.org, en el que las dife-
rencias funcionales se pueden su-
plir con la formación de los usua-
rios.
Las eventuales diferencias entre las soluciones que se tienen que implantar
y las incidencias del proyecto no son insalvables18.
• Proyecto�viable�con�condiciones. El proyecto es viable, pero los requisi-

tos de la implantación requiere emprender un proceso de creación o adap-
tación de soluciones. Las implicaciones temporales y económicas vendrán
dadas por el alcance del proceso, que será máximo cuando sea necesario
un desarrollo completamente nuevo.
• Proyecto�inviable. Aunque en esta etapa no es habitual abortar el proyec-

to, se pueden dar casos en que la organización no quiera continuar con
él. Por ejemplo, por la falta de financiación para afrontar un desarrollo
concreto o cambios en la estrategia de la organización.
• Por una parte, obtendremos las soluciones en software libre más adaptadas
a los requerimientos del proyecto y de la organización.
• Por otra parte, obtendremos una valoración preliminar de los costes rela-
cionados con la etapa de desarrollo del proyecto (implantación directa o
necesidad de un desarrollo adicional).
2.5. Formalización de la propuesta
En este apartado se define la formalización de la propuesta del proyecto de

implantación y se presentan las principales características y particularidades.
Se detallan las diferentes fases que componen el proceso, los principales fac-
tores que influyen en su desarrollo y los resultados que se pueden obtener de
la etapa.
La formalización de la propuesta es la etapa del proyecto donde se con-

cretan, se especifican y se enlazan todos los resultados obtenidos en las
primeras fases metodológicas del proyecto –llamadas etapas de diseño–,
con el objetivo de proponer una solución formal a la problemática de
implantación de sistemas de la organización.
Los objetivos específicos de esta etapa se centran principalmente en tres as-

pectos:
• Caracterización� del� proyecto. La formalización de la propuesta reúne,

clarifica y relaciona todos los resultados de las primeras etapas del diseño
de la implantación de sistemas. El resultado de esta etapa tiene que servir
de guía para el desarrollo posterior de la implantación, por lo cual se hace

notar su importancia dentro del proyecto.
• Validación�por�parte�de�la�organización. La formalización de la propues-

ta también sirve para presentar y evaluar el proyecto de implantación por
parte de la organización. La valoración que resulta concreta el futuro del
proyecto, su viabilidad y su desarrollo y ejecución.
• Reducción�del�riesgo. La formalización de la propuesta permite reducir el

riesgo del proyecto y de la implantación del sistema y delimita el escenario
de evolución del proyecto gracias a la concreción de las soluciones y del
desarrollo de la implantación.
Esta etapa guarda relación con la gestión funcional del proyecto porque per-
mite concretar aspectos de la planificación del proyecto como la gestión de
los tiempos, los recursos y el coste del proyecto, considerando la información
que se obtiene a partir de los resultados de las etapas anteriores.
Globalmente, la propuesta tiene que dar respuesta a dos aspectos principales:
• Aspectos�metodológicos. Los aspectos metodológicos hacen referencia a

los resultados de las etapas de análisis y diseño de la implantación de sis-
temas, vistas en esta unidad. Más concretamente, el análisis del sistema
actual, el análisis de requerimientos y el análisis de soluciones en software
libre. El objetivo es plasmar las características del sistema que se tiene que
implantar como resultado de un proceso metódico y riguroso.
• Aspectos�de�gestión. Los aspectos de gestión hacen referencia a las parti- Ved también
cularidades de funcionamiento y ejecución del proyecto, como la planifi-
Consultad éstos y otros aspec-
cación temporal, la económica o la relativa a los recursos humanos que tos de la gestión de proyectos
harán falta para llevar a término el proyecto. El objetivo es plasmar los en el apartado de "Gestión de
proyectos en software libre" de
parámetros de ejecución del proyecto, ofreciendo una visión clara de los la primera unidad.
requisitos necesarios con el fin de alcanzar los objetivos.
De los anteriores párrafos podemos concluir la importancia de la comunica-

ción y la colaboración con la organización, con el objetivo de transmitir co-
rrectamente toda la información relevante del proyecto. Globalmente, se pue-
den identificar dos aspectos principales de la información que hay que trans-
mitir:
• El�proyecto. La comprensión del proyecto, de los resultados obtenidos en

el análisis y de la solución más adecuada a las características del proyecto.
Es importante que quede clara la relación entre las propuestas del proyecto
y la actuación estratégica que persigue la organización.
• El�software�libre. La comprensión de la utilización del software libre, el

modelo filosófico en el cual se sustenta y las características de las licencias,
así como las particularidades de las soluciones propuestas y los beneficios

que obtiene la organización.
A grandes rasgos, se pueden considerar cuatro grandes fases dentro de la for-

malización de la propuesta: la preparación, el diseño, la presentación y la eva-
luación final.
2.5.1. Preparación de la propuesta
Esta primera fase de formalización de la propuesta pretende recuperar todas

las informaciones plausibles de ser incorporadas en la propuesta de solución.
Se trata de obtener los documentos de resultado de las diferentes etapas de
estudio y análisis, así como de la planificación del proyecto.
Uno de los principales objetivos de esta primera fase es generar resultados

avanzados a partir de los datos iniciales. Es decir, crear resúmenes, esquemas,
tablas, diagramas o gráficos que permitan clarificar los conceptos de los docu-
mentos técnicos que se han desarrollado a lo largo del proyecto.
Otro resultado que se obtiene de esta primera fase es la actualización de la pla-

nificación del proyecto a partir de la información contenida en los diferentes
documentos de análisis. Normalmente, los aspectos más importantes para la
organización son:
• Solución�a�implantar. Es importante la definición de la solución que se Ved también

quiere implantar, los objetivos y el alcance del proyecto, las incidencias
Consultad el apartado "Ges-
estratégicas a las que da solución y los sistemas que serán implantados. tión del tiempo" para conocer
más aspectos del coste tempo-
ral del proyecto.
• Coste�temporal. El coste temporal tiene relación con la planificación tem-
poral de los recursos y de la propia implantación o migración.
• Coste�económico. El coste económico tiene relación con la repercusión Ved también

económica que resulta de implantar el sistema en la organización (mate-
Consultad el apartado "Ges-
rial, recursos, tiempo, formación, etc.) y de la gestión del proyecto (equi- tión del coste" con el fin de co-
po de gestión del proyecto). Hay que tener presente que debe valorarse el nocer más aspectos del coste
económico del proyecto.
coste económico del proyecto desde sus inicios19.
(19)
Tal como se desprende del
Eventualmente, también puede resultar útil preparar los siguientes aspectos: apartado "Recursos de un proyec-
to de implantación de sistemas", el
proyecto se inicia cuando se dota
• Buscar mitos históricos del software libre, especialmente de las soluciones de recursos por primera vez.
propuestas, y argumentar a favor y en contra. El objetivo es ofrecer una
(20)
base de trabajo con el fin de justificar y fundamentar la propuesta ante En inglés FUD (fear, uncertainty
20
and doubt).
las eventuales reticencias al cambio que se puedan observar en su pre-
sentación.
• Obtener y presentar información de tipologías de licencia en software li-

bre, con el objetivo de desmitificar algunas asunciones y transmitir con
fundamentos la filosofía libre y su relación con la solución propuesta.
• Crear tablas DAFO para representar y justificar situaciones en que ha sido

necesario tomar decisiones a partir del estudio y la evaluación de diferentes
opciones. En estos casos, puede ser conveniente evaluar y ponderar cada
una de las alternativas que se presentan.
De esta fase se obtiene un conjunto de documentos con resultados sobre dos

aspectos principales:
• Por una parte, un conjunto de referencias a documentos técnicos de aná-

lisis de las etapas de diseño, así como diversos resultados avanzados e in-
formación relacionada con el proyecto y el software libre.
• Por otra parte, una actualización de la planificación de la gestión del pro-

yecto, que incluirá todos los aspectos derivados de las etapas de análisis y
diseño, que modelan la continuación del proyecto.
2.5.2. Diseño de la propuesta
La fase de diseño de la propuesta pretende confeccionar todos aquellos docu-

mentos y presentaciones que deben presentarse a la organización y que resu-
men el trabajo realizado en las etapas de estudio y análisis del proyecto de
implantación de sistemas.
Esta fase parte de los documentos de la fase anterior, con referencias a docu-
mentos técnicos, información relacionada con el proyecto y con el software
libre, resultados avanzados y actualización de la planificación temporal y eco-
nómica. Se trata de estructurar, organizar y presentar toda la información dis-
ponible a fin de que sirva de guía para el posterior desarrollo del proyecto.
Globalmente, se pueden llegar a generar dos grandes tipos de documentos

diferentes:
• Informes�y�planificaciones: son documentos que presentan los resulta-

dos de un estudio profundizado. Su objetivo es presentar los contenidos
de manera estructurada y metódica, con precisión, orden y rigor, a fin de
que sean utilizados como guía o manual del proyecto.
• Presentaciones: son documentos que muestran el estudio en líneas gene-

rales. Su objetivo es presentar los principales conceptos del estudio de ma-
nera ordenada, sintética y gráfica, a fin de que sean utilizados como resu-
men del proyecto.
Los informes tienen que presentarse editados y compaginados, utilizando un

lenguaje formal y riguroso. Normalmente, un informe contiene los siguientes
elementos:
• Resumen�ejecutivo: es un resumen breve, que ubica el proyecto de im-

plantación de sistemas y su contenido en el tiempo, en el espacio, en los
objetivos y en las soluciones.
• Introducción: presenta la situación estratégica de la organización y la ne-

cesidad de emprender un proyecto de implantación de sistemas en unas
circunstancias concretas.
• Análisis�de�la�situación�actual: tiene que presentar un resumen del estu-

dio, el análisis y las conclusiones del sistema actual de la organización en
relación a su estrategia.
• Definición,�objetivos�y�alcance: se presenta el proyecto de implantación

de sistemas, los conceptos generales de la solución que se propone, la jus-
tificación del uso del software libre y su adecuación a la estrategia de la
organización.
• Arquitectura�del�sistema,�infraestructura�y�tecnología: presenta la ar-

quitectura general y funcional del sistema, la infraestructura que requiere,
la tecnología y los estándares que utiliza, así como las licencias finales.
Eventualmente se pueden presentar pruebas de integración de los diferen-
tes elementos.
• Recursos� humanos� y� materiales: se presentan los recursos humanos y

materiales necesarios para el funcionamiento habitual del sistema dentro
de la organización.
• Implantación�y�mantenimiento: presenta la metodología de implanta-

ción que se seguirá, las características de la migración, la formación de los
usuarios, la adaptación de la organización y el mantenimiento necesario
de la instalación a lo largo del tiempo (normalmente, a un plazo de cinco
años).
• Planificación�temporal: detalla el seguimiento y la relación de las etapas

del proyecto a lo largo del tiempo, con la cosideración de los recursos asig-
nados en cada momento. Normalmente, también se presenta un gráfico
donde se representan las etapas en función del tiempo.
• Planificación�económica: presenta la valoración del coste de llevar a cabo

el proyecto, desglosando las diferentes partidas que componen el coste de
la implantación (por ejemplo, coste de la gestión de los proyectos, recursos
humanos necesarios, gastos de material, desarrollo y ajuste de software,

instalación de infraestructura).
• Sinergias�con�la�comunidad�de�software�libre�y�con�otros�proyectos�u
organismos: eventualmente, y según las características de la organización,
se incluye un apartado que explica la relación de las soluciones utilizadas
con el mundo de la filosofía libre, el aprovechamiento de otros proyectos
similares y la relación con otros organismos o con la comunidad de soft-
ware libre.
• Conclusiones: hay que poner énfasis en las características del proyecto

que solucionan las necesidades estratégicas de la organización y los bene-
ficios que se obtienen del uso del software libre.
• Anexos�técnicos: pueden ser útiles para el desarrollo posterior del proyec-

to. Por ejemplo, el análisis de los requerimientos del sistema.
De esta fase se obtienen dos documentos:
• El informe o plan de proyecto, que se presentará como documentación

técnica del proyecto.
• La presentación, que servirá a la reunión ejecutiva de la fase siguiente.
2.5.3. Presentación de la propuesta
En esta fase se presenta la propuesta a la organización, normalmente enmarca-

da dentro de una reunión ejecutiva con su órgano directivo. El objetivo con-
siste en poner en conocimiento de la organización los resultados finales de las
etapas de análisis, a fin de que puedan valorar la propuesta de solución y el
seguimiento del proyecto, así como evaluar su continuidad.
Normalmente, esta fase se implementa presentando todos los aspectos del pro-
yecto de manera gráfica y resumida, utilizando el documento de presentación
de la fase anterior. De manera adicional a la presentación, se hace entrega del
plan de proyecto con los resultados de las etapas de diseño.
En esta fase es de especial importancia poner de relieve la comunicación y

la transmisión de la información, destacando la relación de la propuesta con
los objetivos estratégicos de la organización. Aunque no es habitual, eventual-
mente se puede pedir la reformulación de algunos aspectos de la propuesta,
que, en cualquier caso, tendrían que ser de poco alcance cuantitativo y cua-
litativo.
Es posible que la comisión que tiene que decidir la implantación del sistema
muestre reticencias al uso del software libre, por lo cual puede convenir jus-
tificar la propuesta desmitificando algunas ideas preconcebidas, presentando
las ventajas e inconvenientes de su uso o, incluso, la filosofía libre en gene-
ral y los modelos de licencia. Puede resultar útil el documento realizado en
la fase de diseño de la propuesta sobre temas relacionados con el proyecto y
el software libre.
Esta fase tiene especial relación con la fase siguiente, de evaluación final, ya
que a menudo las reuniones de presentación son decisorias con respecto a la
continuación del proyecto.
La fase de evaluación final de la formalización de la propuesta es el cuarto pun-

to de control del proyecto y tiene como objetivo valorar el trabajo realizado
en las etapas de diseño de la implantación, así como la propuesta de solución
al proyecto. También tiene el objetivo de resolver la viabilidad y continuidad
del proyecto para las etapas de desarrollo e implantación del sistema.
Esta fase tiene una estrecha relación con la anterior, ya que la presentación
del plan de proyecto y el intercambio de información entre el equipo que ha
realizado el diseño y la organización es fundamental para considerar todas las
implicaciones de la solución presentada. Eventualmente, las fases de presen-
tación y validación de la propuesta se podrían fusionar desde el punto de vista
decisorio sobre la continuación del proyecto.
La importancia de este punto de control es doble:
• Por una parte, porque con la formalización de una propuesta se cierra el

ciclo teórico y conceptual de análisis y diseño del sistema y del proyecto
de implantación que lleva asociado. Las etapas siguientes serán principal-
mente prácticas.
• Por otra parte, porque la organización determinará si el proyecto se com-

pletará finalmente y dará respuesta a la actuación estratégica que lo ini-
ció, con la implantación del conjunto de cambios que se consideran en
la propuesta.
En este sentido, y tal como ya se ha comentado en anteriores apartados, la or-

ganización tiene que valorar los aspectos del proyecto que considere adecua-
dos a su estrategia; por ejemplo, las características de la solución que se quiere
implementar, el coste temporal con el fin de realizar la implantación y el coste
económico del proyecto y de la implantación del sistema.
También puede ser un buen momento para analizar, valorar y adecuar algunos
detalles inherentes a la implantación del sistema en la organización, conside-
rando y concretando algunos aspectos de la gestión del cambio, el calendario
de la implantación, las pruebas piloto o la formación de los usuarios.
La evaluación de la propuesta por parte de la organización puede acabar en

tres grandes tipos de decisiones:
• Proyecto�viable. La organización acepta la solución propuesta sin cam-

bios importantes en sus especificaciones. Los eventuales ajustes pueden
hacer referencia al calendario de la implantación o la inclusión de algunas
partidas económicas, por ejemplo.
• Proyecto�viable�con�condiciones. La organización considera que se ne-

cesitan ajustes en la propuesta de solución. Los cambios pueden ser de
mayor o menor consideración, pero en cualquier caso habrá que rehacer
una parte de la propuesta si se quiere que el proyecto siga adelante. Estos
cambios pueden tener relación con las herramientas implantadas o con la
ejecución parcial del proyecto, por ejemplo.
• Proyecto�no�viable. La organización considera que el proyecto no es via-

ble y se aborta la implantación del sistema. Aunque no es habitual que
pase en esta etapa del proyecto, un cambio drástico en la estrategia de
la organización o la incapacidad para asumir económicamente la finaliza-
ción del proyecto pueden ser causas plausibles del aborto prematuro de la
implantación.
• Por una parte, se obtiene el plan de proyecto, acordado y validado con la

organización.
• Por otra parte, se obtiene la decisión sobre la continuación e implementa-

ción del proyecto.
2.6. Desarrollo
En este apartado se define la etapa de desarrollo del proyecto de implantación

y se presentan las principales características y particularidades. Se detallan las
diferentes fases que componen el proceso, los principales factores que influyen
en su desarrollo y los resultados que se espera obtener de la etapa.
El desarrollo del sistema es la etapa en que se implementan las solucio-

nes que se especifican en el plan de proyecto, así como todos los re-
quisitos relacionados con su puesta en marcha. El objetivo principal es
adecuar, recolectar y producir todos los elementos necesarios con el fin
de realizar la implantación con el máximo de garantías de eficiencia y
eficacia, minimizando el tiempo de intervención.
Esta etapa parte de los documentos de la etapa anterior, principalmente el plan

de proyecto y el análisis de requerimientos del sistema que se quiere implantar.
Estos documentos son fundamentales para preparar, estructurar y organizar el
desarrollo de todos los componentes necesarios para implantar el proyecto.
Los objetivos específicos de esta etapa se centran principalmente en dos as-

pectos:
• Implementación�de�la�solución. El desarrollo pretende implementar la Ved también

solución que determina el plan de proyecto y el estudio de los requeri-
En el apartado "Verificación
mientos, independientemente de la forma que tome el tipo de desarrollo. de los requerimientos" de es-
te módulo se han presentado
tres tipologías de proyecto: la
• Reducción� del� riesgo. El desarrollo también pretende reducir el riesgo implantación directa, la evolu-
ción de herramientas existen-
global del proyecto, preparando, concretando y construyendo la solución tes y el desarrollo de una nue-
sin afectar directamente al funcionamiento de la organización. va solución.
Globalmente, el desarrollo tiene que dar respuesta a dos aspectos principales: Ved también
Consultad el apartado 1.2.2

• Aspectos�metodológicos. Los aspectos metodológicos hacen referencia a "Clasificación por objetivo de
la tipología del proyecto, por lo cual la etapa de desarrollo tiene una rela- los proyectos" con el fin de co-
nocer las diferentes tipologías
ción directa con el objeto de la implantación. Es decir, la metodología de de proyectos en función del
objetivo.
desarrollo que habrá que aplicar dependerá del objetivo del proyecto.
• Aspectos�de�gestión. Los aspectos de gestión hacen referencia a los impli- Ved también
cados en el desarrollo, es decir, a los encargados de implementar las tareas
Consultad el apartado "Recur-
que se recogen en el plan de proyecto. A grandes rasgos, se puede consi- sos de un proyecto de implan-
derar un desarrollo interno (insourcing) o externo (outsourcing). tación de sistemas" de la pri-
mera unidad con el fin de co-
nocer más aspectos del desa-
rrollo interno y externo.
A grandes rasgos, se pueden considerar tres grandes fases dentro de la etapa de
desarrollo: la dotación de recursos, la configuración o desarrollo de software
y la evaluación final, aunque la existencia individual de estas etapas depende
en gran medida de la tipología del proyecto.
Hay que precisar que las fases de dotación de recursos y desarrollo de softwa-
re se pueden ejecutar de manera simultánea en el tiempo, en función de la
tipología del proyecto. También es posible que la superposición temporal sea
sólo parcial, a causa de diferencias en el calendario de entrega de los diferentes
recursos, por ejemplo.
También hace falta tener en cuenta que la etapa de desarrollo guarda una es-
trecha relación con la siguiente, la de implantación o migración del sistema.
En este caso, eventualmente también se puede producir la superposición o si-
multaneidad temporal de algunas tareas con el fin de reducir el calendario del
proyecto, aunque puede tener consecuencias económicas que hay que valorar,
como la necesidad de más recursos humanos y materiales, por ejemplo.
2.6.1. Dotación de recursos
Esta primera fase de dotación de recursos pretende seleccionar y adquirir todos

los recursos necesarios para la implantación del sistema en la organización. Se
trata de obtener todos aquellos elementos que tienen una relación de prerre-
quisito directa para la implantación y explotación del nuevo sistema.
(21)
Uno de los principales objetivos de esta primera fase es dotar la organización de Como, por ejemplo, la instala-
ción de una red de área local, la
la infraestructura necesaria con el fin de poner en funcionamiento el sistema.
habilitación de un local técnico o
Es decir, todos aquellos recursos materiales, organizaciones y configuraciones la compra de conmutadores, orde-
nadores y servidores.
que tienen que permitir al nuevo sistema ser operativo21. En este sentido, si
el proyecto incluye la migración total o parcial del sistema, puede resultar
Ved también
eficiente enlazar esta fase con la de planificación de la migración.
Consultad los apartados "Estra-
tegias de migración", "Inven-
Normalmente, la dotación de recursos materiales se adjudica evaluando las tario de hardware y software"
y "Diagrama de red y de es-
características de las propuestas de los proveedores según un conjunto de ba- tructura" con el fin de conocer
ses específico. Este conjunto de bases tiene que crearse a partir de los requeri- más aspectos de la planifica-
ción de la migración.
mientos del sistema, con el fin de poder garantizar la adecuación y la integra-
ción con el resto del proyecto.
La evaluación de las diferentes propuestas es particular en relación con el pro-

yecto, el sistema y la organización. A grandes rasgos, se pueden valorar los
siguientes aspectos:
• Sistema�e�interoperabilidad: hay que valorar cada elemento en sí mismo,

su adecuación e integración en el sistema, en el proyecto y en la organi-
zación.
• Funcionalidad�y�ergonomía: hay que valorar la facilidad de manipula-

ción y configuración del elemento, así como de los conocimientos nece-
sarios para la puesta a punto y su utilización cotidiana.
• Eficiencia� y� rendimiento: hay que valorar el rendimiento funcional y

operativo en relación a las necesidades del sistema.
• Eficacia�y�fiabilidad: hay que valorar la fiabilidad y la consecución de los

objetivos en relación a los requerimientos del sistema.
• Implantación�y�migración: hay que valorar la facilidad para implantar el

elemento en el entorno de la organización y las herramientas que incor-
pora para migrar con respecto a la solución actual.
• Mantenimiento,�soporte�y�garantía: hay que valorar las necesidades para

el funcionamiento y mantenimiento del elemento, así como el soporte y
las garantías que ofrecen los proveedores.
• Economía: hay que valorar la relación entre el coste del elemento y los
resultados que ofrece, las ventajas e inconvenientes del impacto en el fun-
cionamiento de la organización.
Por otra parte, la implantación del proyecto también puede requerir la dota-
ción de recursos humanos en la organización, ya sea para la manipulación di-
recta o indirecta del sistema. Hay que destacar que el proyecto surge de una
actuación estratégica de la organización y que, por lo tanto, es posible que el
cambio de métodos y procedimientos implique una reestructuración del per-
sonal implicado.
En este sentido, el caso extremo correspondería a una organización de nueva

creación, o a una organización ya creada pero que no disponga de ningún so-
porte informático para su funcionamiento. La demanda de perfiles tecnológi-
cos iría en consonancia con el grado de implantación tecnológica, la tipología
del proyecto y las características de la organización.
De todos modos, la selección de los recursos humanos tendría que integrarse

en la metodología habitual de selección que utiliza la organización, pero habrá
que destacar la necesidad de adecuar el perfil del candidato a los requisitos
tecnológicos del sistema y de la nueva estrategia de la organización.
2.6.2. Configuración y/o desarrollo de software
La fase de desarrollo de software pretende implementar todos los ajustes que

requiere la solución en software libre con el fin de adecuarse al plan de proyec-
to. También se puede incluir en esta etapa el desarrollo de herramientas que
puedan ayudar a la conversión de datos o ficheros en la migración del sistema.
El principal objetivo de esta fase es garantizar la idoneidad de la solución en

software libre a los requisitos del proyecto, con el ajuste y codificación de todos
los cambios que sean necesarios, aprovechando la apertura del código fuente
y la libertad para ser modificado.
La amplitud de esta fase dependerá directamente de los cambios que se tengan

que introducir en la propuesta. Globalmente, se pueden distinguir tres casos
diferentes:
• Implantación�directa. En el caso de la implantación directa de software,

el escenario de desarrollo se limita al eventual ajuste de los ficheros de
configuración o parámetros del software.
Por ejemplo, la configuración del sistema operativo (idioma, acceso a la
red, etc.) o parámetros de herramientas de ofimática (plantillas, idioma,
etc.). Este caso supone una inversión temporal y económica ínfima con
respecto a los otros dos casos.
• Evolución�del�software. La evolución del software considera la amplia-

ción o adecuación del código fuente de una o más soluciones de software
libre, con el objetivo de ajustar su funcionamiento al de la organización.
La importancia de los resultados incide en la necesidad de proceder con
el rigor habitual de la ingeniería del software, estableciendo un ciclo de
vida adecuado para cada modificación; eventualmente, de reingeniería del
software.
Por ejemplo, la introducción de cálculos adicionales en el software de ges-
tión contable o la modificación del gestor de descargas de un navegador
web.
• Desarrollo�nuevo. El caso del desarrollo de código nuevo considera que Ved también
no existe ninguna solución adecuada a las necesidades específicas de la or-
Podéis ampliar los conocimien-
ganización. Sin embargo, puede resultar útil estudiar y reutilizar el código tos metodológicos para la pro-
fuente de aplicaciones abiertas con el fin de ganar tiempo y fiabilidad. ducción de software libre en la
asignatura de "Ingeniería del
El desarrollo nuevo es el más laborioso en términos de coste temporal y software en entornos de soft-
ware libre".
económico. Estas implicaciones inciden en la necesidad de proceder se-
gún metodologías de ingeniería del software adecuadas al proyecto. Por
ejemplo, la creación de software de diseño industrial o arquitectónico o
de control electrónico de dispositivos.
En este sentido, cualquier proyecto de desarrollo de software se guiará por su

ciclo de vida particular y establecerá los hitos de control y de calidad opor-
tunos, evaluando el seguimiento y los resultados según la metodología más
adecuada.
Independientemente del formato de desarrollo, es aconsejable realizar en esta

fase la documentación del proceso de adecuación del software, con la lista
y descripción de todos los detalles que han estado sujetos a modificaciones,
con el mismo rigor que en desarrollos nuevos. En estas circunstancias hay

que tener presente la licencia final de la solución que se evoluciona, ya que
normalmente la libertad del código fuente se hereda de la solución original.
En esta fase también puede convenir desarrollar los materiales de formación

de los usuarios del sistema, así como ajustar los manuales de soporte de las
soluciones en software libre, ya que se dispone de todos los elementos nece-
sarios para su realización. En estos casos, también hay que tener en cuenta las
características de las licencias de los manuales que se pretende modificar.
Manuales de soporte
Las preguntas más frecuentes (PMF, en inglés FAQ, frequently asked questions) o los habi-
tuales manuales de resolución de tareas concretas (how to en inglés), que a pesar de tener
un marcado aspecto técnico, pueden ser de gran ayuda.
La fase de evaluación final de la etapa de desarrollo es el quinto punto de

control del proyecto, y tiene el objetivo de garantizar que el desarrollo sigue los
requisitos del plan de proyecto. También tiene el objetivo de reducir el riesgo
global del proyecto, mediante la validación de la viabilidad y adecuación del
desarrollo a la estrategia de la organización.
Normalmente, la evaluación de esta etapa depende de la tipología del propio

desarrollo:
• Recursos,�instalaciones�e�infraestructuras: se valoran según el cumpli-

miento de los objetivos con respecto al diseño y la propuesta del provee-
dor. Hay que señalar la importancia de los plazos de entrega y su repercu-
sión en la planificación temporal de otras etapas.
• Implantación�directa�de�software: se valora el cumplimiento de los obje-

tivos de los ajustes de configuración y la operativa prevista. La evaluación
principal se considera sobre las pruebas de funcionamiento.
• Evolución�o�desarrollo�de�software: la complejidad de la valoración es

proporcional a la magnitud de los cambios introducidos. Normalmente, se
considera la valoración que resulta del proceso de ingeniería del software.
(22)
Esta fase tiene una estrecha relación con la implantación y la migración del Como, por ejemplo, la interfaz
gráfica, la respuesta del sistema o
sistema, ya que en función del tipo de proyecto, se pueden implantar las so-
las características de los procedi-
luciones a medida que finalice su desarrollo. Eventualmente, también puede mientos que implementa el mis-
mo.
tener relación con la formación de los usuarios y las pruebas piloto, ya que
puede ser útil conocer las apreciaciones de los usuarios con el fin de perfeccio-
nar algunos detalles del desarrollo22.
La importancia de este punto de control es doble:
• Por una parte, porque revisa, evalúa y valora el desarrollo cualitativo de las
soluciones y su adecuación a los requisitos estratégicos de la organización.
• Por otra parte, porque supone la finalización del proceso de creación y

adecuación de la solución y el inicio de la implantación e integración de-
finitiva del sistema en la organización.
(23)
En general, la fase de evaluación del desarrollo es un buen momento para in- En inglés, FUD (fear, uncertainty
and doubt).
troducir a los usuarios en las particularidades del sistema, y se podrá conside-
rar la situación como inicio de la formación y adaptación de los usuarios al
nuevo entorno. Estas actuaciones se pueden enmarcar dentro de la gestión del
cambio que tiene que llevar a cabo la organización, con el objetivo de vencer
las eventuales reticencias y miedos de los usuarios23.
La evaluación final de la etapa de desarrollo puede acabar en tres grandes tipos

de decisiones:
• Sistema�viable�para�ser�implantado. La evaluación determina que el sis-

tema cumple los requisitos de la organización y que se han desarrollado
y se han integrado correctamente todas las modificaciones de la solución
original. Se puede iniciar la implantación del sistema en la organización.
• Sistema�viable�para�ser�implantado�parcialmente. La evaluación deter-

mina que el sistema cumple parcialmente los requisitos del proyecto en la
fecha de control. Esta situación se debe normalmente a retrasos en la pro-
ducción, que pueden ser consecuencia de imprevistos relacionados con la
falta eventual de recursos materiales, el decalaje excesivo en su entrega o
la falta de efectivos humanos para la producción.
En cualquier caso, la viabilidad del proyecto no se ve afectada aunque ha-
brá que asumir un retraso en la implantación.
• Sistema�inviable�para�ser�implantado. Aunque no es habitual que el de-

sarrollo de una solución resulte inviable, es posible que excepcionalmen-
te pueda haber factores que afecten a la resolución y no se hayan podido
solucionar durante la etapa. Este tipo de problemas se relacionan normal-
mente con factores externos al proyecto, como por ejemplo cambios brus-
cos en la estrategia o el agotamiento de la dotación económica.
El aborto prematuro del proyecto en esta etapa tiene fuertes implicaciones
económicas, funcionales y morales en la organización, y dificultará posi-
bles actuaciones futuras.

• Por una parte, se obtiene el sistema que se quiere implantar, probado e

integrado, con el objetivo de responder a los requisitos del proyecto y a
las necesidades estratégicas de la organización.
• Por otra parte, se obtiene la valoración de la viabilidad de la implantación

y eventuales ajustes en la planificación temporal, como consecuencia de
la evaluación de eventuales pruebas piloto.
2.7. Implantación y migración
En este apartado se profundizará en los detalles técnicos de la implantación y

la migración a sistemas basados en software libre.
La mayoría de los proyectos de implantación son también proyectos de

migración, ya que parten de un escenario en el cual hay un sistema in-
formático basado en software propietario que se encuentra ya en pro-
ducción. Los casos de implantación desde cero se dan en organizaciones
de nueva creación que para la puesta en marcha de su primer sistema se
orientan hacia una solución basada en software libre, o bien en organi-
zaciones que hasta ahora no disponían de ningún sistema informático,
lo cual pasa muy pocas veces.
Con respecto a los problemas técnicos que el proyecto tiene que resolver, la
implantación desde cero es siempre mucho más sencilla que la migración,
principalmente porque no se encontrará ningún problema de compatibilidad
hacia atrás. No obstante, hay que tener en cuenta que los usuarios del nuevo
sistema normalmente estarán familiarizados con sistemas operativos y aplica-
ciones de propiedad, por lo que la planificación de la formación es tan impor-
tante como en un proyecto de migración.
En este apartado siempre haremos referencia a proyectos de migración, porque

son los que presentan una mayor dificultad y también porque los proyectos
de implementación desde cero se pueden considerar como un subconjunto
de los proyectos de migración, con la particularidad que en este caso se tiene
más libertad para decidir el escenario final. Esta libertad presenta como con-
trapartida la necesidad de prestar más atención a aspectos no funcionales del
sistema, como dimensionarlo correctamente, por ejemplo.
Así, se presentarán, en primer lugar, los diferentes tipos de proyectos de mi-

gración y los aspectos más importantes de la planificación. En segundo lugar,
se darán algunos consejos y orientaciones para ejecutar la migración y evaluar
su resultado. Finalmente, se estudiarán en detalle todos los servicios implica-

dos en el proyecto de migración, así como las soluciones basadas en software
libre más populares para cada uno de ellos.
2.7.1. Tipos de migración
Dentro de una organización se pueden llevar a cabo diferentes tipos de migra-

ción a sistemas basados en software libre: según los objetivos, es decir, según
cuáles sean los elementos del sistema que serán migrados, y según el alcance,
es decir, según la cantidad de elementos que serán migrados.
Según el objetivo:
(24)
• Migración�de�servicios�y�servidores: afecta a los servidores de la organi- OpenBSD, FreeBSD o NetBSD.
zación y a las aplicaciones o servicios que se ejecutan, por ejemplo, el ser-
vicio de autentificación o el servicio de impresión, entre otros. En este caso Ved también
las aplicaciones de los clientes no cambian, por lo cual sólo hay que pre-
En el apartado "Diagrama de
ver formación para los administradores de sistemas, y no para los usuarios red y diagrama de estructura"
se verán en detalle las particu-
finales. Son una de las migraciones más fáciles de llevar a cabo. En gene- laridades de la migración de
ral, los servidores, funcionando con sistemas operativos GNU/Linux, de cada uno de estos servicios.
la familia BSD24 u otros igualmente libres, suelen ser más fiables y ofrecen
un rendimiento superior, lo cual aumentará la productividad de la orga-
nización, tanto de los administradores de sistemas como de los usuarios
finales (menos tiempo de respuesta del servidor).
• Migración� de� usuarios� y� clientes: afecta a las máquinas cliente de los

usuarios y a las aplicaciones que en ellas se ejecutan. En este caso se tiene
que prever que será necesario formar y acompañar a los usuarios finales,
que en general son menos receptivos a la utilización de nuevas aplicacio-
nes y sufrirán más el cambio, con una posible pérdida de productividad
temporal.
• Migración�de�aplicaciones: afecta tan sólo a algunas de las aplicaciones

que se ejecutan en los servidores o en las máquinas cliente, el sistema ope-
rativo del cual no tiene por qué ser GNU/Linux u otro sistema operativo
libre. De hecho, lo más habitual es que el sistema operativo continúe sien-
do de propiedad. A veces es un paso previo a la migración del sistema ope-
rativo. Son migraciones bastante sencillas de llevar a cabo, por ejemplo la
migración a OpenOffice.org o a MySQL Community Server.
Según el alcance:
• Migración�completa: resulta de la combinación de migrar tanto los ser-

vidores como las máquinas cliente. La planificación de este tipo de migra-
ción tiene que garantizar que los clientes no queden en ningún momento
sin acceso a los servicios proporcionados por los servidores. Para ello, se
suele realizar en primer lugar la migración total o parcial de los servidores

y, a continuación, la migración de las máquinas cliente.
• Migración�parcial: resulta de la combinación de migrar tan sólo una par-

te de los servidores o una parte de los clientes, de manera que continúa
habiendo en el sistema máquinas basadas en software propietario. Un es-
cenario habitual es aquél en el cual, en el mismo sistema, se encuentran
clientes basados en software libre y clientes basados en software propieta-
rio, cuya configuración dependerá de las necesidades o preferencias de los
usuarios finales.
• Migración� basada� en� la� virtualización: puede considerarse un tipo de

migración parcial, en la cual se lleva a cabo la migración de servidores y
máquinas clientes al mismo tiempo que se continúan instalando y ejecu-
tando aplicaciones basadas en software propietario que no se ha podido
incluir en la migración, ya sea por la ausencia de equivalentes en software
libre o por otras razones. La virtualización permite iniciar un sistema ope-
rativo de propiedad sobre un sistema operativo libre y utilizarlo a todos
los efectos, ejecutando aplicaciones basadas en software propietario.
Por otra parte, hay que tener en cuenta que, si bien el escenario típico de
migración es aquél en el cual se pasa de un sistema operativo de propiedad a
GNU/Linux, existen otras posibles combinaciones, como son:
• De un sistema operativo de propiedad a un sistema operativo libre, por

ejemplo los pertenecientes a la familia BSD.
• De un sistema operativo libre a otro sistema operativo libre.
El sistema operativo OpenBSD
El sistema operativo OpenBSD destaca por la calidad de sus mecanismos de seguridad y

la integración de la criptografía integrada, lo cual lo hace especialmente indicado para
servidores u otro tipo de máquinas cuya integridad pueda verse comprometida.
2.7.2. Estrategias de migración
Como en todo proyecto, una planificación correcta es una condición impres-

cindible para asegurar el éxito de la migración a un sistema basado en softwa-
re libre. Hay tantas planificaciones como proyectos, y todas serán más o me-
nos válidas si se ajustan a los requisitos y las particularidades del escenario de
migración planteado. Sin embargo, según la planificación de la migración, se
pueden extrapolar cuatro grandes estrategias de migración:
• Migración� en� un� único� paso: implica llevar a cabo todo el proceso de
migración en un corto espacio de tiempo, si puede ser en un solo día,
o en días de fiesta. Esta estrategia requiere identificar y definir todas las
tareas que se tienen que realizar, ya que un error en una de ellas puede
dejar sin servicio a todo el sistema, con el consiguiente riesgo de retrasos
y rechazo por parte de los usuarios. Esta estrategia es la más económica y

se suele aplicar en sistemas de dimensiones reducidas, con pocos clientes
y un único servidor, por ejemplo en el caso de pequeñas empresas.
• Migración�piloto: implica llevar a cabo, en primer lugar, la migración de

una pequeña parte del sistema, con la cual se practicará y evaluará el éxito
de la migración, antes de proceder a la implantación en el resto del sistema.
El sistema piloto consiste en unos cuantos servidores y máquinas cliente,
incluso podría tratarse de un solo servidor y una sola máquina cliente. Si
bien una planificación correcta es muy importante, esta estrategia permite
una mayor flexibilidad para modificar el planteamiento de la migración
y corregir posibles problemas. En contrapartida, esta estrategia requiere
muchos más recursos y, por lo tanto, suele utilizarse en organizaciones con
sistemas medianos o grandes.
• Migración�por�grupos: implica definir grupos de usuarios según sus ca-

racterísticas funcionales y llevar a cabo la migración gradualmente con ca-
da uno de estos grupos. Una de las principales ventajas de esta estrategia
es que permite minimizar los riesgos e ir aprendiendo en cada una de las
migraciones. Además, sólo una parte del sistema se ve afectado por la mi-
gración, lo cual permite suavizar la pérdida de productividad. Como con-
trapartida, a menudo hay que mantener los sistemas anteriores en funcio-
namiento, mientras se va desplegando el sistema basado en software libre.
La migración por grupos normalmente es un buen momento para renovar
el hardware, y viceversa.
• Migración�por�usuarios: es similar a la migración por grupos, con la par-

ticularidad que sólo se migra un usuario cada vez. En consecuencia, esta
estrategia necesita muy pocos recursos pero es inviable en organizaciones
grandes y medianas, en las cuales el elevado número de usuarios prolonga-
ría durante demasiado tiempo la migración. No obstante, puede ser acon-
sejable para llevar a cabo la migración de sistemas y usuarios críticos que
necesiten un seguimiento especial.
Estas estrategias no son exclusivas y dentro de un mismo proyecto se pueden

aplicar varias. Por ejemplo, en una organización en la cual ciertos departamen-
tos de tamaño más reducido o de menor importancia lleven a cabo una mi-
gración en un único paso, y otros en los cuales se lleve a cabo una migración
piloto antes de la implantación completa. De la misma manera, la migración
por grupos se puede ver como una combinación de la migración en un solo
paso y la migración piloto.
2.7.3. Inventario de hardware y software
Para planificar la migración hace falta identificar el hardware y el software

existente en la situación inicial, y de cuáles se espera disponer después de la
migración. En consecuencia, se tiene que hacer un inventario detallado tanto
del hardware como del software.
El inventario de hardware tiene que incluir todas las máquinas disponibles

para la migración, incluidas las máquinas retiradas, ya que algunas se pueden
reutilizar.
El hardware se puede clasificar en las categorías siguientes:
• Hardware�soportado�sin�problemas�en�GNU/Linux: se incluye hardware

que desde el origen es soportado por el núcleo Linux o por controladores
libres, así como hardware para el cual hay que utilizar controladores de
propiedad, sea directamente o mediante adaptadores. La mayoría de hard-
wares dispone de un buen soporte en GNU/Linux, por lo cual se clasifica
en esta categoría. Más adelante se detallará cada una de estas situaciones.
(25)
• Hardware�soportado�con�algunas�limitaciones�en�GNU/Linux: se in- Como por ejemplo, adaptado-
res gráficos con aceleración 3D cu-
cluye hardware que funciona únicamente en versiones antiguas del nú-
yos controladores libres sólo dispo-
cleo Linux, que no son las utilizadas en las distribuciones GNU/Linux más nen del modo 2D.
recientes, hardware que funciona con controladores muy antiguos para

los cuales no existe mantenimiento y hardware cuyos controladores li-
bres presentan limitaciones funcionales con respecto a los controladores
25
de propiedad .
Distribución GNU/Linux
La producción de una distribución GNU/Linux implica la verificación que todos los pa-
quetes incluidos en la distribución son compatibles entre ellos y, especialmente, con la
versión del núcleo. Por ello hay siempre un desfase de diversos meses entre la fecha de
aparición de la distribución y la de su núcleo, más antiguo.
(26)
• Hardware�no�soportado�en�GNU/Linux: se incluye el hardware que no No obstante, en este caso, una
solución basada en la virtualización
funciona de ninguna manera en GNU/Linux. Realmente, hay muy poco
podría ser posible.
hardware que no disponga de soporte en GNU/Linux y, cuándo eso pasa,
se debe bien al hecho de que el hardware es muy nuevo y todavía no se
han desarrollado los controladores apropiados, bien al hecho de que el
hardware es muy antiguo y es incompatible con versiones más nuevas del
núcleo Linux, bien al hecho de que el hardware es dependiente de un
sistema operativo en concreto y, por lo tanto, inutilizable en GNU/Linux26.
A su vez, el hardware soportado por GNU/Linux se puede clasificar según el

tipo de soporte de la siguiente manera:
• Hardware� soportado� desde� el� origen� por� GNU/Linux: la mayoría de Página web
equipos y sus dispositivos disponen de un soporte adecuado en las distri-
Podéis informaros sobre
buciones GNU/Linux recientes, y por eso no hay que recurrir a controla- hardware soportado por
dores externos. Es fácil encontrar en Internet listas del hardware soporta- GNU/Linux en: http://
hardware4linux.info/.
do por GNU/Linux.
• Hardware�soportado�por�controladores�libres: una parte importante de Página web

los dispositivos, si bien no están soportados desde el origen por GNU/Li-
NDISwrapper es un proyecto
nux, funcionan correctamente con controladores mantenidos por la code software libre que permi-
munidad de software libre. A menudo, los gestores de paquetes incluidos te utilizar tarjetas de red ina-
lámbricas bajo GNU/Linux
con las distribuciones GNU/Linux proponen la instalación de estos con- mediante controladores Win-
troladores cuando detectan el hardware. dows.
• Hardware�soportado�por�controladores�propietarios: para este tipo de

dispositivos no hay controladores mantenidos por la comunidad de soft-
ware libre, y entonces hay que utilizar controladores propietarios a menu-
do suministrados por el mismo fabricante. Suele tratarse de hardware con
funcionalidades muy específicas, por ejemplo las aceleradoras gráficas. Sin
embargo, poco a poco el soporte para este tipo de dispositivos va aumen-
tando y a menudo los mismos fabricantes liberan sus controladores.
• Hardware�soportado�mediante�adaptadores: son aquéllos para los cua-

les no hay soporte en GNU/Linux, pero sí para otros sistemas operativos
de propiedad. Afortunadamente, hay herramientas denominadas adapta-
dores que permiten utilizar controladores de estos sistemas operativos de
propiedad bajo GNU/Linux.
La clasificación correcta del hardware permitirá hacerse una idea precisa de

los recursos disponibles, así como de la necesidad eventual de comprar nue-
vos equipos. Por otra parte, como se ha comentado anteriormente, se puede
destacar que los requisitos de hardware de los sistemas GNU/Linux son consi-
derablemente menores que los de los sistemas operativos de propiedad, por lo
cual máquinas obsoletas pueden reutilizarse con el fin de ofrecer servicios de
impresión o de correo electrónico, entre otros.
Una vez hecho el inventario de hardware, habrá que hacer un inventario de

software. Eso implica identificar todas las aplicaciones que se utilizan en el
sistema antes de la migración, basadas en software propietario, y las mejores
aplicaciones basadas en software libre que puedan sustituirlas.
En Internet hay muchas listas con las equivalencias entre aplicaciones de pro- Página web
piedad y libres. Sin embargo, a veces habrá que llevar a cabo un estudio deta-
El proyecto SourcePYME
llado de las funcionalidades de cada aplicación para escoger al mejor candida- ofrece una lista de aplicacio-
to entre las opciones basadas en software libre. nes y servicios bastante ex-
tensa y actualizada (http:/
/www.sourcepyme.org/
Cuando se trata de aplicaciones de uso más común, como las ofimáticas, el ?q=node/13). Hay igualmen-
te un gran número de recur-
número de opciones es elevado y a menudo hay una aplicación o un paquete sos en inglés.
de aplicaciones que destaca por encima de las otras. Para aplicaciones de usos
más específicos a menudo hay comunidades de desarrolladores y usuarios, en
Ved también
las cuales puede ser interesante pedir consejo y a veces implicarse y todo.
En el apartado "Evaluación de
la migración" se presentarán
En caso de que no haya aplicaciones ni proyectos basados en software libre, las alternativas existentes pa-
la organización podría evaluar la posibilidad de desarrollar la aplicación en ra la migración de los servicios
esenciales de una organiza-
la medida de sus necesidades y liberarla bajo una licencia libre, siempre que ción.
disponga de bastantes recursos. Los beneficios son evidentes: la contribución

potencial de desarrolladores y usuarios externos y el aumento de la visibilidad
para la organización.
2.7.4. Diagrama de red y diagrama de estructura
En este apartado se presentarán dos elementos esenciales en una migración de

sistemas: el diagrama de red, que muestra la conectividad entre los diferentes
elementos del sistema, y el diagrama de estructura, que indica su ubicación
física.
De esta manera, una vez se conoce el hardware y el software que se verá afec- Página web
tado por la migración, se pasará a representar el sistema mediante un diagrama
Una excelente aplicación de
de red. El diagrama de red tiene que contener los elementos siguientes: software libre para realizar
diagramas de red, entre otros
tipos de diagramas, es Dia
• Servidores. Se indicará el nombre del equipo, junto con los principales (http://live.gnome.org/Dia).
servicios ofrecidos por cada servidor.
• Equipos�cliente�o�de�usuario. Se indicará el nombre del equipo, así como

los dispositivos de red que estén expuestos al resto del sistemas.
• Impresoras. Se indicará el nombre de la impresora y de qué servidor de

impresión o de qué equipo cliente dependen.
• Otros�equipos�de�red. Se indicarán los principales equipos que formen la

red del sistema y permitan la conectividad entre los diferentes equipos. Por
ejemplo concentradores o hubs, encaminadores o routers, conmutadores
o switches y puntos de acceso inalámbrico o access points.
• Conectividad�entre�los�elementos. Se indicarán las conexiones de red por

cable e inalámbricas entre los diferentes elementos del sistema. Se indicará
igualmente la salida a redes externas desde la red local de la organización
como Internet, redes privadas virtuales (VPN) y organizaciones virtuales

(VO).
En el diagrama de red es muy importante que cada equipo esté identificado

de manera unívoca.
En primer lugar, se hará un diagrama de red que recoja el estado del sistema
antes de la migración. A partir de este diagrama se estudiarán cuáles son las
posibilidades de optimización de la red actual, como resolver cuellos de botella
en los servidores o conectar ciertas impresoras locales en un servidor central
de impresión. De la misma manera, se decidirá qué equipos nuevos y qué ele-
mentos de red se introducirán en el sistema como nuevos servidores, equipos
antiguos que puedan funcionar con GNU/Linux o el despliegue de una red
inalámbrica.
Con estos elementos se construirá el diagrama de red del sistema posterior

a la migración. Este diagrama será esencial para definir la planificación y la
estrategia de la migración, y mientras dure la implantación servirá siempre
de guía. Por eso convendrá mantener el diagrama de red siempre al día, de
manera que refleje fielmente el estado del sistema.
Como se ha comentado al principio del apartado, el diagrama de estructura

refleja la ubicación física de los equipos dentro de la organización o, dicho de
otra manera, nos indica qué equipos hay en cada sala.
De la misma manera que se ha hecho con el diagrama de red, se diseñará

un diagrama de estructura que represente el estado del sistema antes de la
migración a partir del cual se podrá decidir la ubicación de los equipos después
de hacer la migración.
Una de las consecuencias más frecuentes de la migración es la puesta en mar-

cha de servidores dedicados a un reducido número de servicios, a veces incluso
en exclusiva. Por ello los servidores suelen agruparse en la misma ubicación
física (típicamente una sala de servidores), que presentará requisitos particu-
lares de climatización, suministro de energía y accesibilidad, entre otros. Otro
ejemplo es la conexión de impresoras (hasta ese momento locales) en un ser-
vidor de impresión, que se pueden ubicar en la misma sala.
Si bien en organizaciones reducidas, con un entorno de una decena de equi-

pos, el diagrama de estructura no es especialmente importante, en escenarios
de migración extensos resulta imprescindible para ubicar cada uno de los equi-
pos y elementos de red.
2.7.5. Ejecución de la migración
En la ejecución de toda migración, e independientemente de la estrate-

gia de migración que se haya adoptado, hay una serie de tareas técnicas
que casi siempre se repiten: instalación de equipos, migración de datos,
realización de copias de seguridad, emulación de aplicaciones. Junto
con estas tareas técnicas, destaca la importancia de disponer de un plan
de gestión de los riesgos que pueden presentarse en la migración.
En este apartado veremos brevemente cada una de estas tareas y daremos al-
gunas orientaciones para llevarlas a cabo:
•� Instalación� de� equipos. Hay herramientas de instalación automática de

equipos con el fin de poder instalar y configurar fácilmente muchos en un
tiempo reducido.
Una de estas herramientas es SystemImager, que permite automatizar la ins- Pàgina web
talación de imágenes o clones del sistema GNU/Linux instalado en un primer
Podéis encontrar más
equipo. SystemImager permite también distribuir nuevas aplicaciones o datos información sobre Sys-
en los equipos del sistema y realizar cambios en la configuración o instalar temImager en http://
wiki.systemimager.org/.
actualizaciones del sistema en redes con equipos GNU/Linux. Sin embargo, en
caso de que el hardware de los equipos no sea idéntico, puede ser que haya
que configurarlos manualmente. SystemImager
SystemImager permite guardar

•�Migración�de�datos�de�usuario. Los nombres y direcciones de los usuarios la imagen de un sistema GNU/
Linux en producción antes de
suelen almacenarse en servicios de directorio, normalmente accesibles a través realizar cambios en el sistema,
del protocolo estándar LDAP, que facilita la migración de estos datos a nivel lo que garantiza poder volver a
la situación original.
del sistema.
Sin embargo, al nivel de las aplicaciones que hacen uso de estos datos, como Ved también
clientes de correo o aplicaciones para trabajo en grupo, se suelen utilizar es-
Podéis consultar el apartado
quemas de datos diferentes para estructurar la información. En consecuencia, "Inventario de hardware y soft-
ware" para obtener más deta-
los datos son pocas veces interoperables entre ellos y entonces hay que utilizar lles sobre la migración de ser-
programas externos que sincronicen los datos entre aplicaciones. vicios de directorio.
•� Realización� de� copias� de� seguridad. En general, las copias de seguridad

hacen referencia a la copia de datos de manera que estas copias adicionales
permitan restaurar un sistema después de una pérdida de información. La im-
plantación de sistemas GNU/Linux comporta a menudo el formateo y parti-
ción de los equipos implicados en la migración, por lo cual habrá que realizar
copias de seguridad de los datos existentes, con el fin de restaurarlas después
en el nuevo sistema.
Si la organización dispone de un mecanismo de copia de seguridad actuali-

zado, una buena opción es utilizarlo para recuperar toda la información que
tenga que ser copiada en los nuevos equipos.
Si la organización no dispone de ningún mecanismo de copia de seguridad, se

puede poner en marcha un servicio de almacenamiento exclusivamente para
almacenar los datos que tienen que migrar. Otra opción es desplegar en primer
lugar el servicio de almacenamiento previsto en el plan de proyecto y propor-
cionar acceso a los usuarios del sistema de manera que puedan almacenar sus
datos antes de migrar los equipos de usuario. En cualquiera de estos dos casos,
la participación de los usuarios es fundamental.
(27)
Por otra parte, una vez concluida la migración hará falta poner en marcha Hay múltiples soluciones dis-
27 ponibles, entre las cuales destaca
un mecanismo de copias de seguridad incremental . Como regla general, el RSync (http://samba.anu.edu.au/
sistema original y la copia tienen que ser cuanto más independientes mejor, rsync) y Amanda (http://
amanda.org).
de manera que un error en uno no afecte al otro.
•�Emulación�de�aplicaciones�y�virtualización. La realización del inventario

de software servirá para saber qué aplicaciones no se pueden ejecutar de mane-
ra nativa en GNU/Linux y tampoco pueden ser sustituidas por una aplicación
libre equivalente. En caso de que estas aplicaciones sean imprescindibles, hay
dos posibles soluciones con el fin de poder continuar utilizándolas: la emula-
ción y la virtualización.
Wine, la solución libre más popular
Wine es la solución libre más popular para ejecutar aplicaciones nativas de Windows en
un sistema GNU/Linux. Aunque se suele decir que Wine (http://www.winehq.org/) es un
emulador, es más correcto afirmar que Wine proporciona una capa de compatibilidad
para aplicaciones Windows. De hecho, Wine corresponde a las siglas de Wine is not an
emulator (Wine no es un emulador).
Wine no necesita instalar ninguna partición Windows, aunque en algunos casos puede
convenir disponer de algunas bibliotecas nativas de Windows. Las aplicaciones ejecuta-
das con Wine pueden acceder al sistema de archivos, la red y los servicios de impresión
de manera completamente transparente. En el sitio web de Wine pueden consultarse qué
aplicaciones están soportadas y con qué nivel de funcionalidad.
Para aplicaciones que no se ejecuten correctamente con Wine hay la posibilidad de eje-
cutarlas en un sistema operativo virtualizado. Como se ha introducido anteriormente,
la virtualización permite ejecutar un sistema operativo encima de otro. En este caso se
trataría de ejecutar la aplicación en un sistema Windows virtual sobre un sistema GNU/
Linux. Las soluciones libres más populares de virtualización son QEMU, Xen i KVM. En
cualquier caso, la virtualización siempre se tiene que considerar en último lugar, ya que
implica continuar utilizando y pagando licencias de propiedad y supone un gran consu-
mo de recursos del sistema.
•�Gestión�de�riesgos. La migración a un sistema basado en software libre es Ved también

un proceso que no está exento de riesgos, por lo cual es importante preparar
Podéis consultar el apartado
un plan de gestión y mantenerlo durante toda la ejecución del proyecto. "Gestión de riesgos" para obte-
ner más detalles sobre la reali-
zación de planes de gestión de
riesgos.
Los riesgos y su importancia relativa dependerán del escenario de migración y

de las particularidades de la organización. Por ejemplo, para ciertas organiza-
ciones puede ser una prioridad garantizar la seguridad e integridad de ciertos
datos confidenciales, por lo cual se tendrá que prevenir esta contingencia y
definir un plan para solucionarla en caso de que finalmente ocurra.
Como regla general, se sugiere que el proceso de migración sea reversible hasta
que no se haya verificado completamente el nuevo sistema, es decir, que se
pueda volver a la situación de partida en el caso improbable de que la migra-
ción falle o acabe siendo inviable.
2.7.6. Evaluación de la migración
En todo proyecto de migración es esencial llevar a cabo una evaluación

tanto del sistema final como del proceso de migración. Esta evaluación
puede hacerse una vez concluida la migración, pero también durante la
misma, en caso de que ésta no se realice en un único paso.
El plan de proyecto tiene que incluir, por lo tanto, una serie de indicadores
bien definidos. Algunos de estos indicadores pueden ser los siguientes, según
hagan referencia al sistema operativo, a los servidores, a las aplicaciones o a
los usuarios:
• Indicadores�del�sistema. ¿Se ha aumentado la fiabilidad, el rendimiento

y la seguridad del sistema después de la migración? ¿Cómo ha variado el
coste real (no estimado) de mantenimiento del sistema? ¿Se han desplega-
do nuevos servicios en el sistema? ¿Cuál es la valoración de los adminis-
tradores del nuevo sistema? ¿Ha disminuido el número de incidencias de
los diferentes servicios del sistema después de la migración?
• Indicadores�del�sistema�operativo. ¿Cuántos equipos han sido migrados

al nuevo sistema? ¿Funcionan correctamente todos los equipos? ¿Todo el
hardware está soportado en el nuevo sistema? ¿Cuántas veces ha habido
que recurrir a soluciones basadas en la virtualización?
• Indicadores�de�las�aplicaciones. ¿Para cuántas de las aplicaciones exis-

tentes se ha encontrado y ha sido implantada una aplicación equivalente
en software libre? ¿Qué funcionalidades se han ganado o se han perdido
con respecto a las aplicaciones originales? ¿Cuántas aplicaciones funcio-
nan bajo emulación o virtualización? ¿Cuántas aplicaciones ha sido nece-
sario modificar? ¿Cuántas aplicaciones se han tenido que desarrollar des-
de cero?
• Indicadores�de�los�usuarios. ¿Cuántos usuarios han sido migrados al nue-

vo sistema? ¿Cuál es su valoración de los aspectos funcionales y no fun-
cionales del nuevo sistema y de las nuevas aplicaciones? ¿Cuál ha sido la

variación de su productividad a corto y largo plazo? ¿Ha disminuido el
número de incidencias de usuario al instalar el nuevo sistema operativo?
2.7.7. Migración de los servicios de un sistema
En la mayoría de las organizaciones hay una serie de servicios esenciales,

a los cuales se tiene que prestar especial atención a la hora de planificar
y ejecutar la migración:
• Sistema de archivos
• Servicio de impresión
• Servicio de directorio y autentificación
• Servicio de red
• Gestión y administración del sistema
• Servidores web
• Bases de datos
• Entornos de escritorio y aplicaciones ofimáticas
• Aplicaciones corporativas
En este apartado, se presentarán las características principales de estos servi-

cios y se mostrarán las soluciones basadas en software libre más populares.
En general, siempre hay más de una alternativa, por lo que la elección final
dependerá de las características y requisitos de cada escenario.
Aclaración
Si bien la mayoría de las soluciones basadas en software libre que se presentan en este
apartado se encuentran en un estado maduro de desarrollo y se utilizan en muchos es-
cenarios, la tecnología evoluciona continuamente, por lo cual es aconsejable visitar los
sitios web de cada uno de los proyectos para obtener la información técnica más reciente
e investigar otras soluciones que pudieran mejorar las existentes.
Igualmente, la importancia de cada uno de estos servicios será diferente en

función de las características de la organización. Es posible que algunos de
estos servicios no se encuentren presentes en la situación inicial y, por lo tanto,
no se incluyan en la migración.
Sin embargo, la migración representa una excelente oportunidad para analizar

y revisar el estado actual del sistema y diseñar una arquitectura que responda
tanto a las necesidades actuales de la organización como a aquéllas necesarias
a largo plazo. Por ello se tiene que considerar la inclusión de nuevos servicios
no presentes en el sistema original.
Sistema de archivos
En la migración del sistema de archivos pueden darse dos situaciones, según

si migran todos los clientes o tan sólo una parte:
•�Migración�del�servidor�del�sistema�de�almacenamiento�pero�no�de�los
clientes
En este caso, la opción más popular es el uso de Samba. Samba es una imple-
mentación libre del protocolo utilizada en sistemas de archivos compartidos
de Microsoft Windows para sistemas Unix que permite que ordenadores con
GNU/Linux actúen como servidores o clientes en redes Windows.
•�Migración�del�servidor�del�sistema�de�almacenamiento�y�de�los�clientes
En este caso, habitualmente se tiene en cuenta el uso de NFS o de OpenAFS.
(28)
NFS permite acceder a archivos remotos dentro de una misma red como si OpenAFS es una implementa-
ción libre de un sistema de archi-
se tratara de archivos locales. NFS viene incluido por defecto en el sistema
vos originariamente desarrollado
operativo GNU/Linux. De forma similar, OpenAFS28 es un sistema de archivos por la Universidad Carnegie Me-
llon, que influyó también en el di-
distribuido, utilizado generalmente en centros de servidores (clusters) y en seño de NFS.
escenarios de computación distribuida.
La elección entre el uno y el otro (o la elección de otro sistema) dependerá de

los requisitos de la migración. Es posible utilizar NFS o OpenAFS en redes que
incluyan clientes Windows y GNU/Linux.
Para la migración de los servidores que funcionan con GNU/Linux, hay múl-
tiples sistemas de archivos, pero los más conocidos son Ext3 y XFS. Sus fun-
cionalidades incluyen journaling, asignación de cuotas y privilegios de acceso
basados en ACL (Access Control List) por archivo y directorio.
Un aspecto a tener en cuenta en la migración del sistema de archivos es el

mapeo de las ACL Windows a las ACL Posix, en el cual se puede perder cier-
ta granularidad. En la práctica eso no suele pasar, ya que habitualmente las
organizaciones hacen un uso completo de la granularidad permitida por las
ACL Windows.
Servicio de impresión
La impresión es una de las fuentes de problemas más recurrentes en todas las

organizaciones, en general a causa de la instalación de impresoras sin ninguna
planificación, cosa que comporta numerosas incidencias técnicas y, a menudo,
el despilfarro de recursos (papel, tinta, electricidad). De hecho, la migración a
un sistema basado en software libre se presenta como una buena oportunidad
para optimizar el servicio de impresión.
Entre las soluciones basadas en software libre, CUPS es el servidor de impre-

sión utilizado por la mayoría de distribuciones GNU/Linux y es de hecho la
mejor opción en casi todos los escenarios de migración. Una de sus principales
ventajas es que permite disponer de un servicio de impresión tanto para clien-
tes GNU/Linux como para clientes Windows, gracias a la implementación del
protocolo de impresión por Internet (Internet Printing Protocol, IPP).
El protocolo IPP es un estándar de impresión tanto en redes LAN como WAN

y soporta la comunicación entre cliente y servidor, entre diferentes servidores
y entre servidor y la impresora seleccionada. Todas las impresoras modernas
lo soportan.
Hay que tener en cuenta que antes de llevar a cabo la migración se tienen que
comprobar el soporte y los controladores existentes para cada impresora.
Servicio de directorio y autentificación
Un servicio de directorio tiene como finalidad que una determinada informa-

ción esté disponible para todos los usuarios de una red. Esta información nor-
malmente está compuesta por objetos que se organizan de una manera jerár-
quica, con su origen en un objeto raíz. El protocolo que se utiliza más a me-
nudo para acceder es el LDAP.
LDAP (Lightweight Directory Access Protocol)
Inicialmente, el LDAP hacía referencia sólo al protocolo de acceso. Sin embargo, hoy en
día se entiende por LDAP la combinación de la base de datos que contiene la información
y el protocolo para acceder a ella.
Por ejemplo, un uso bastante frecuente de un servicio de directorio es almace-

nar las cuentas de los usuarios del sistema junto con sus privilegios, de manera
que todas las aplicaciones y servicios del sistema pueden acceder a él con el
fin de obtener este tipo de información, que dada su naturaleza es aconsejable
que sea íntegra.
Así, un servicio de directorio tiene que ofrecer las siguientes funcionalidades:
• Tiene que modificar la información disponible y organizarla según una

estructura jerárquica.
• Tiene que usar un esquema de datos estándar, que asegure la compatibili-
dad y la interoperabilidad con el mayor número de aplicaciones.
• Tiene que autentificar usuarios y garantizar la interoperabilidad con otros
servicios de autentificación.
• Tiene que administrar los derechos de acceso a la información contenida
en el servicio de directorio.
• Tiene que garantizar la seguridad en la transmisión de la información entre
los clientes y el servicio de directorio.
Con el fin de llevar a cabo la autentificación junto con un servicio de direc-

torio, la solución basada en software libre más frecuente es la combinación
de OpenLDAP con Samba, en la cual éste último sirve como base de datos de
las cuentas de usuario, mientras que OpenLDAP actúa como servicio de direc-
torio. Un gran número de aplicaciones son compatibles con LDAP, como el
paquete ofimático OpenOffice.org.
(29)
El sistema GNU/Linux ofrece diversas herramientas LDAP29 que permiten mo- Por ejemplo, ldapsearch, lda-
pad y ldapmodify.
dificar la información almacenada en el servicio de directorio, y hay también
diferentes interfaces gráficas basadas en Web para la administración de usua-
rios y grupos.
Un servicio de directorio y autentificación basado en OpenLDAP y Samba per-

mite además el uso de clientes Windows y Linux simultáneamente. De hecho,
OpenLDAP actúa al mismo tiempo como parte del servicio de autentificación
y como herramienta de integración en escenarios mixtos con clientes GNU/
Linux y Windows. En caso de que la migración a GNU/Linux sea completa, es
posible también llevar a cabo la autentificación mediante Kerberos. Kerberos
es un protocolo de autentificación que permite que dos ordenadores demues-
tren mutuamente su identidad de una manera segura.
Servicios de red
Toda la infraestructura de redes TCP/IP (DNS, DHCP, NTP, conexión de enca- Nota
minadores, filtraje, VPN) puede implementarse fácilmente mediante solucio-
Podéis consultar más informa-
nes basadas en software libre, lo cual se debe principalmente al hecho de que ción de los estándares abiertos
todos los protocolos de Internet son estándares abiertos, tanto en su defini- en el anexo II de este módulo
didáctico.
ción como en sus implementaciones.
Un aspecto a considerar en la migración de los servicios de red es la utilización

de estándares abiertos, incluso en el caso en que no se tengan que utilizar (por
ejemplo, en el caso de una pequeña red local), y así evitar el uso de modifica-
ciones específicas de los fabricantes de hardware, que a la larga podrían provo-
car problemas de incompatibilidad con otros sistemas a la hora de implantar
nuevos servicios, e incluso una dependencia del fabricante.
Entre los servicios de red destacan los siguientes:
•�DNS�(sistema�de�nombres�de�dominio�o�domain�name�system)
La implementación de referencia en software libre es BIND (Berkeley Internet Internet Systems

Name Domain), mantenida en la actualidad por la Internet Systems Consor- Consortium
tium (ISC). BIND es el servidor de DNS más utilizado en Internet. La última Internet Systems Consortium
versión es BIND 9, que incorpora DNSSEC (DNS Security Extensions), TSIG es una organización sin ánimo
de lucro y el sucesor del Inter-
(Transaction Signature), notificación DNS, nsupdate y Ipv6 entre otras funcio- net Software Consortium, tam-
bién denominado ISC.
nalidades. Está disponible en todos los sistemas GNU/Linux.
•�DHCP�(protocolo�dinámico�de�configuración�de�huésped�o�dynamic�host
configuration�protocol)
La implementación de referencia en software libre es dhcpd, también mante-

nida en la actualidad por el ISC. dhcpd permite administrar clientes individua-
les y configuraciones colectivas para clases y subredes. Además, dhcpd ofrece
funcionalidades de balance de carga y alta disponibilidad. Está disponible en
todos los sistemas GNU/Linux.
•�NTP�(protocolo�de�tiempo�de�red�o�network�time�protocol)
NTP es un protocolo de Internet que permite sincronizar los relojes de los sis-
temas informáticos a través de el encaminamiento de paquetes, para evitar los
problemas derivados de latencia variable en las redes. El NTP Project propor-
ciona soporte para NTP y ofrece una implementación de referencia, disponible
en todos los sistemas GNU/Linux.
•�WINS�(Windows�Internet�name�service)
WINS permite resolver los nombres de los diferentes servicios y sistemas Win-
dows. Esta función se puede sustituir por nmbd, incluido en el paquete Samba.
Gestión y administración del sistema
La mayoría de aplicaciones de control y de gestión de sistemas no son nativas

en el sistema operativo y los fabricantes a menudo proporcionan versiones de
estas aplicaciones para diferentes sistemas operativos. Esta situación presenta
el inconveniente de que si bien hay un buen número de aplicaciones de ges-
tión de sistemas para GNU/Linux, no están basadas en software libre.
En cualquier caso, la gestión y el control de sistemas basados en software li-

bre es muy diferente de la de sistemas basados en software propietario, como
Windows. Los administradores de sistemas basados en software libre normal-
mente no utilizan una única herramienta de gestión, sino un conjunto, cada
una de las cuales especializada en una parte del sistema. De esta manera, los
administradores tienen mucha más libertad para realizar ajustes y corregir los
posibles problemas de sus sistemas, lo cual es una de las causas de la conocida
fiabilidad y seguridad asociadas al software libre.
Una primera opción para la automatización de tareas de administración en

GNU/Linux es la utilización de cron y at. El primero (cron) es un adminis-
trador de procesos en segundo plano que ejecuta programas a intervalos regu-
lares. De una manera similar, la orden at permite la ejecución de programas
en un momento determinado.
Por otra parte, todo sistema GNU/Linux ofrece la funcionalidad básica de ad-
ministración a través de una terminal remota ssh en otro cliente o servidor,
exactamente de la misma manera que si se tratara de su máquina local, inclu-
so a través de la interfaz gráfica del escritorio. El uso combinado de ssh con
cron y at permite al administrador realizar una buena parte de las tareas de
mantenimiento.
Además, otras utilidades del sistema como strace, lsof o netstat ofrecen
diferentes funcionalidades para detectar y analizar errores y pueden resultar
útiles en la gestión de servidores.
•�Gestión�de�red
Entre las soluciones disponibles para la gestión de redes TCP/IP como software
libre se puede destacar Nagios y openNMS.
Nagios permite monitorizar servidores y servicios para detectar problemas de

red en sistemas basados en GNU/Linux. Un proceso en segundo plano contro-
la los servidores y servicios especificados y envía la información al servidor de
Nagios, que a su vez notifica al administrador del sistema en caso de que se
detecte algún problema. Mediante una serie de plugins, Nagios permite moni-
torizar de manera activa y pasiva servicios de red típicos como servidores de
Web y de correo, pero también otros, como sistemas gestores de bases de datos.
Por su parte, openNMS es una aplicación de gestión de redes que cumple el

modelo FCAPS y permite determinar la disponibilidad de los diferentes servi-
cios, almacenar la información y generar informes y notificar acontecimien-
tos.
No obstante, hay que tener en cuenta que la gestión de sistemas y redes de

más complejidad puede requerir utilizar herramientas que no están disponi-
bles como software libre.
•�Gestión�de�software
La gestión de software implica la instalación y restauración de clientes, las dis-

tribuciones de aplicaciones estándar y específicas y la gestión de actualizacio-
nes y parches en todo el sistema.
Entre las soluciones disponibles como software libre se puede destacar m23,
un paquete de software para sistemas basados en la distribución Debian, que
permite la instalación inicial de los clientes, incluyendo la definición de par-
ticiones y la detección de hardware, la distribución y actualización de software
y la restauración de clientes.
Servidor web
Apache es la principal alternativa para migrar e implantar el servidor web de El proyecto Apache
una organización. Apache está presente en más del 60% de los servidores web
Apache es uno de los proyec-
y se distribuye libremente bajo la licencia Apache. tos desarrollados por la co-
munidad de software libre de
más éxito, y a causa de ciertas
Sus funcionalidades y rendimiento son excelentes y están sobradamente con- particularidades de su licencia
puede ser utilizado en produc-
trastados en todo tipo de escenarios de producción. La arquitectura de Apache tos de software propietario.
es modular y consiste en un núcleo que contiene las funcionalidad básicas del
servicio y un gran número de módulos fácilmente instalables para aplicacio-
nes específicas, como para soportar determinados lenguajes de programación
como PHP, Java, Perl, etc.
(30)
La migración de proyectos web30 en un servidor web basado en Apache exige el Por proyecto web se entiende
tanto una página web (por ejem-
estudio de las particularidades de cada proyecto, que a veces pueden dar lugar a plo, la página web de la organiza-
incompatibilidades. Apache soporta perfectamente tanto contenidos estáticos ción) como las aplicaciones basa-
das en web y accesibles a través de
(desarrollados en HTML) como dinámicos (desarrollados en lenguajes como un navegador.
PHP o Perl). Normalmente, las modificaciones que se tienen que aplicar en
estos proyectos para asegurar su compatibilidad bajo Apache serán mínimas
o nulas.
Un caso especial son los proyectos desarrollados en tecnologías de propiedad

como ASP, que requieren un esfuerzo importante para que funcionen bajo
Apache. Siempre que sea posible, es preferible implementar de nuevo el pro-
yecto web en tecnologías alternativas como PHP, de manera que se asegure
la independencia tecnológica en el futuro. Eso supone sin duda un esfuerzo
mayor, que en cambio se puede aprovechar para optimizar los contenidos y
aplicaciones web de la organización.
De hecho, la utilización de PHP como lenguaje de programación para la Web

es cada vez más frecuente y en los últimos años se han generalizado las plata-
formas LAMP (Linux, Apache, MySQL y PHP) con el fin de ofrecer contenidos
y aplicaciones web.
Bases de datos
Hay muchas alternativas en software libre para la implantación de sistemas

gestores de bases de datos, pero las más conocidas son MySQL, PostgreSQL,
Firebird y MaxDB. La elección de una solución u otra dependerá del análisis
de los requisitos de la migración.
En cualquier caso, las bases de datos libres son productos maduros que han
sido probados en entornos de producción y, de hecho, se pueden considerar
como una de las puntas de lanza del software libre y del sistema GNU/Linux
en los entornos empresariales. Hay que destacar también que estas soluciones
cuentan con versiones para sistemas operativos de propiedad, por lo cual po-
drían utilizarse en una migración únicamente de aplicaciones.
(31)
Algunas bases de datos de propiedad como Oracle31 disponen también de una Oracle suele utilizarse en en-
tornos bastante complejos que
versión para GNU/Linux, por lo que en los casos concretos en los cuales no presentan una serie de requisitos
fuere aconsejable migrar el sistema gestor de base de datos, sí que sería posible que a veces las soluciones libres no
ofrecen.
realizar la migración del sistema operativo en GNU/Linux.
La mayoría de bases de datos ofrecen mecanismos más o menos estándar para

su administración y consulta, lo cual en principio favorece la interoperabilidad
y la utilización de otras soluciones, así como una migración fácil de los datos
de un sistema gestor a otro, de manera que las aplicaciones puedan continuar
accediendo a los datos de manera transparente y sin necesidad de ninguna
modificación adicional.
De esta manera, la migración de bases de datos implica llevar a cabo dos ope-
raciones:
• Migración�de�datos�a�la�nueva�base�de�datos. Esta operación requerirá

más o menos esfuerzo según el estado inicial de los datos. En caso de que
los datos sean accesibles mediante consultas SQL, una operación de expor-
tación o trasvase de datos y la posterior importación a la nueva base de
datos tendría que ser suficiente. En caso de que los datos se encuentren
almacenados en algún formato de propiedad o incluso en ficheros de tex-
to, hará falta implementar un analizador sintáctico (parser) e importarlos
después a la nueva base de datos.
• Verificación�del�acceso�a�datos�desde�las�aplicaciones. En caso de que

las aplicaciones utilicen un mecanismo estándar para leer los datos, por
ejemplo consultas SQL, el acceso se tendría que realizar de la misma ma-
nera, excepto si se utilizan comandos que no satisfacen el estándar. En
caso de que las aplicaciones utilicen controladores estándar como ODBC
o JDBC, o una interfaz propietaria, será necesario sustituir el controlador
de la base de datos original por el de la nueva base de datos, o bien imple-
mentar una interfaz nueva. En ambos casos, este paso puede suponer un
esfuerzo considerable y dar lugar a problemas de interoperabilidad.
Como regla general, y con el fin de facilitar la migración de bases de datos, se

debe evitar como sea la utilización de procedimientos de consulta predefini-
dos y extensiones específicas de los fabricantes en el acceso a los datos desde
las aplicaciones. Por contra, es recomendable utilizar controladores estándar
como ODBC o JDBC, fácilmente intercambiables, e implementar las consultas
SQL de la manera más modular y aislada con respecto al resto del programa.
Entornos de escritorio y aplicaciones ofimáticas
En los sistemas GNU/Linux hay dos grandes alternativas de entornos de escri-

torio: GNOME y KDE.
Tanto GNOME como KDE proporcionan un entorno de escritorio intuitivo que

incluye un gestor de ventanas fácil de utilizar para cualquier tipo de usuario
y una plataforma de desarrollo que permite construir aplicaciones integradas
con el resto del escritorio y entre ellas.
La elección entre uno u otro depende en gran manera de los gustos personales.
En general, KDE ofrece una interfaz más similar a la de Windows y más posi-
bilidades de personalización, que sin embargo pueden suponer una dificultad
adicional para los nuevos usuarios.
Por otra parte, si bien hay un gran número de aplicaciones ofimáticas para los
sistemas GNU/Linux que se integran bien con los sistemas de escritorio Gno-
me y KDE, hay dos soluciones que destacan de entre las otras: OpenOffice.org
y StarOffice.
OpenOffice.org es un paquete ofimático de software libre y código abierto de

distribución libre. Está disponible para múltiples plataformas tanto libres co-
mo de propiedad, por lo cual se encuentra a menudo como ejemplo de migra-
ción de aplicación. En la mayoría de los casos es compatible con Microsoft
Office y soporta el estándar ISO OpenDocument para el intercambio de datos,
que puede ser utilizado libremente.
(32)
De hecho, OpenOffice.org está basado en el proyecto StarOffice. StarOffice es Fuentes TrueType similares a las
utilizadas por Microsoft, plantillas y
el paquete ofimático de propiedad y de pago de Sun Microsystems y contiene
galerías de imágenes adicionales y
algunas funcionalidades adicionales32 con respecto a OpenOffice.org, a la cual parches y actualizaciones adiciona-
les, entre otros.
Sun Microsystems continúa dando su apoyo.
Tanto OpenOffice.org como StarOffice incluyen diferentes aplicaciones, cada

una de las cuales con unas funciones concretas, pero que se integran perfec-
tamente las unas con las otras:
• Procesador de textos (Writer)

• Hoja de cálculo (Calc)
• Presentación (Impress)
• Editor de fórmulas matemáticas (Math)
• Dibujo (Draw)
• Base de datos (Database)
(33)
OpenOffice.org33 utiliza un formato comprimido de archivos basado en XML La mayoría de características de
OpenOffice.org que se citarán en
para todas sus aplicaciones, que difiere de los formatos binarios utilizados por el apartado son extensibles a Sta-
otras aplicaciones ofimáticas de propiedad. Este formado permite separar fá- rOffice.
cilmente el contenido del archivo de sus datos, sus estilos, el control de versio-
nes y las imágenes incluidas en el documento. OpenOffice.org permite igual-
mente trabajar con otros formatos basados también en XML.
Migración�de�archivos�en�formato�Microsoft�Office
OpenOffice.org incluye también mecanismos para convertir e importar archi-

vos en formatos de propiedad, como los utilizados por el paquete ofimático
Microsoft Office. De la misma manera, permite guardar archivos creados con
OpenOffice.org en formatos de propiedad.
Sin embargo, esta compatibilidad no es completa, y si bien la calidad suele

ser en la mayoría de los casos aceptable, en ocasiones pueden aparecer dife-
rencias en el formato de los documentos, sobre todo en aquéllos que incluyen
elementos complejos, como macros u otras características especiales. En este
caso puede ser que sea necesario reeditar algunos de estos documentos si se
quiere que su formato sea idéntico al del original.
Por ello, antes de convertir y migrar los documentos, hace falta estudiar las
particularidades y clasificarlos según su uso y su complejidad técnica:
• Documentos editables: tienen que ser convertidos a un nuevo formato

interoperable, como ODT, de manera que puedan ser editados en el futuro.
• Documentos de sólo lectura: podrían ser convertidos al formato PDF, lo

cual simplifica considerablemente el proceso de migración.
• Documentos sencillos: no contienen macros, gráficos de propiedad, for-

matos o estilos o elementos complejos, como notas al pie, tablas e índices.
Pueden migrarse fácilmente mediante un tratamiento por lotes (batch).
• Documentos complejos: pueden contener macros, gráficos de propiedad

y gráficos vectoriales, objetos OLE, objetos activos, referencias cruzadas,
etc. Se pueden migrar, pero lo más probable es que exijan un tratamiento
individual.
OpenOffice.org ofrece la posibilidad de convertir un gran número de docu-

mentos mediante un tratamiento por lotes. Todos los documentos se tendrán
que encontrar en un directorio de origen y se especificará un directorio de
destino, en el cual se guardarán todos los documentos convertidos. De todos
modos, es recomendable verificar la exactitud de la conversión con una mues-
tra representativa de todos los documentos.
Por otra parte, cuando se trate de documentos complejos, hay dos posibilida-
des:
• Realizar la conversión documento a documento, de manera que se pue-

dan corregir las eventuales diferencias con el documento original, antes
de guardarlo en el nuevo formato.
• Revisar los documentos uno a uno para eliminar los elementos que puedan
afectar al proceso de conversión y, a continuación, realizar un tratamiento
de todos ellos por lotes.
Aplicaciones corporativas
Por aplicaciones corporativas se entienden aquéllas que han sido desa-

rrolladas a medida, para responder a las necesidades concretas de la em-
presa u organización sobre la cual se lleva a cabo la migración.
A los efectos de la migración, podemos distinguir entre los tipos de aplicacio-

nes corporativas siguientes:
• Aplicaciones que pueden ejecutarse sin problemas en un sistema operati-

vo libre, como las aplicaciones multiplataforma (como las elaboradas en
lenguaje Java) o las aplicaciones basadas en web (por ejemplo, en lenguaje
PHP, como se ha visto en el apartado sobre servidores web).
• Aplicaciones que exigen ligeras modificaciones a fin de que se puedan eje-

cutar en un sistema operativo libre. Por ejemplo, para acceder correcta-
mente a las bases de datos, como se ha visto en el apartado sobre este tema,
o para configurar las nuevas variables de entorno.
• Aplicaciones que pueden ejecutarse mediante emulación o virtualización.
• Aplicaciones que no pueden ejecutarse en un sistema operativo libre. Por

ejemplo, las aplicaciones implementadas en lenguajes exclusivamente pa-
ra el sistema operativo de propiedad.
La mayoría de aplicaciones corporativas son propietarios y en consecuencia la

empresa no dispone del código fuente. En caso de que no sea posible ejecutar
de ninguna manera la aplicación mediante emulación o virtualización, la op-
ción más recomendable es implementar de nuevo la aplicación como software
libre, basándose, a ser posible, en algún proyecto de software libre ya existente.
2.8. Formación, comunicación y soporte al usuario
Hasta ahora se han presentado mayoritariamente los aspectos técnicos de la

implantación de sistemas basados en software libre. La importancia de la tec-
nología no debe esconder que uno de los factores de éxito de cualquier pro-
yecto de implantación, y en especial en las situaciones de migración, es la
aceptación del nuevo sistema por parte de sus usuarios.
En este apartado se presentará en primer lugar los elementos principales del

plan de formación en software libre en una organización y algunas buenas
prácticas con el fin de facilitar la introducción y la aceptación de los usuarios.
Para concluir, se repasarán los principales canales de comunicación y los ele-
mentos fundamentales de un sistema de soporte al usuario.
2.8.1. Formación
La formación adecuada de los usuarios tiene un papel importantísimo

en el éxito del proyecto y, por lo tanto, tiene que estar prevista desde
un primer momento en el plan del proyecto.
A la hora de planificar la formación se tiene que identificar en primer lugar

qué grupos de usuarios utilizarán unos tipos de aplicaciones concretas u otros.
De esta manera se podrán estudiar las diferencias entre las aplicaciones de
propiedad y las libres y, en consecuencia, evaluar la dificultad que supondrá
la adopción de las nuevas aplicaciones para los usuarios. Con estos elementos
será posible planificar una formación a la medida de las necesidades reales de
cada usuario.
Hay aplicaciones libres que son muy similares a sus equivalentes de propiedad,
como los navegadores, los clientes de correo electrónico o las aplicaciones ofi-
máticas. Es evidente que en estos casos la necesidad de formación será menor.
Materiales
Hay un gran número de materiales en Internet que pueden utilizarse para la

formación de los usuarios o para preparar materiales propios.
Hay que tener en cuenta que a menudo los manuales y la documentación es-
tán disponibles sólo en inglés, lo cual puede suponer un problema para algu-
nos de los usuarios. La interfaz de algunas aplicaciones no está traducida o su
traducción es incompleta. En estos casos se puede considerar la edición de una
documentación propia, orientada a solucionar los problemas de idioma.
El proyecto europeo SELF proporciona una plataforma para crear y compartir

materiales educativos sobre software libre y estándares abiertos.
Responsable�de�la�formación
La formación puede realizarse dentro de la propia organización, en colabora-

ción con una empresa externa o a través de una plataforma de aprendizaje
en línea.
En cualquiera de los casos, es importante facilitar tanto como sea posible el

acceso a la formación y a sus materiales. Según la política de la organización,
la asistencia a las actividades de formación puede ser obligatoria o no.
Las plataformas de aprendizaje en línea ofrecen la ventaja que los usuarios

pueden ajustar el proceso de aprendizaje y su acceso a la formación de acuer-
do con sus necesidades. Moodle es un sistema de gestión de cursos libre que
permite crear lo que se denominan comunidades�de�aprendizaje�en�línea,
en la cual los alumnos pueden seguir la formación y comunicarse entre ellos.
Una buena opción puede ser la combinación de formación presencial y un

sistema de aprendizaje en línea.
Finalmente, no se tiene que descartar el ofrecer algún tipo de incentivo a los

usuarios para motivarlos a participar en la formación, por ejemplo la conce-
sión de certificados de asistencia y de aprovechamiento.
Tipos�de�usuarios
Los usuarios no son todos iguales. En primer lugar, hay siempre algunos usua-
rios que son más receptivos hacia el nuevo software que otros. No obstante,
en la mayoría de los casos, una vez los usuarios han superado sus reservas ha-
cia el uso del software libre lo encuentran muy similar al software propietario
y están satisfechos con su utilización. Por lo tanto, no hay que preocuparse
mucho en caso de que las primeras experiencias sean negativas.
En segundo lugar, hay que tener en cuenta que el personal técnico y no técnico
necesitará una formación y un seguimiento diferente.
El personal técnico necesitará llevar a cabo un esfuerzo superior que el de los

usuarios normales, especialmente si no tienen ninguna experiencia previa en
software libre y algunos están habituados a trabajar con un sistema de pro-
piedad que, en cambio, dominan perfectamente. Por otra parte, la participa-
ción del personal técnico es muy importante para asegurar el funcionamiento
del sistema una vez implantado. Una buena práctica es motivarlos y hacerlos
partícipes del proceso de implantación, de manera que puedan hacer suyo el
sistema mientras éste se va poniendo en marcha.
2.8.2. Introducción del software libre
Al margen de la formación, otra de las prácticas que pueden facilitar el éxito

de un proyecto de migración de software libre es introducir las nuevas aplica-
ciones y servicios gradualmente, de manera que los usuarios tengan tiempo
de ir habituándose al nuevo entorno y no se encuentren con un sistema to-
talmente desconocido.
Instalación�de�aplicaciones�puente
Hay un buen número de aplicaciones de escritorio cuyo uso está muy extendi-
do y que están disponibles tanto en sistemas operativos de propiedad como en
GNU/Linux, como el paquete ofimático OpenOffice.org, el navegador Firefox
o el cliente de correo electrónico Thunderbird. Hay también diversos servicios
o aplicaciones de servidor que se pueden ejecutar en ambos sistemas, como el
sistema gestor de bases de datos MySQL y el servidor web Apache.
(34)
Este tipo de aplicaciones se denominan aplicaciones puente y pueden ser muy Sería una migración de aplica-
34 ciones sencilla, como la que se ha
útiles a la hora de empezar la migración y evaluar la respuesta de los usuarios visto en el apartado sobre tipos de
y precisar mucho mejor sus necesidades de formación. migración.
Migración�escalonada�de�los�servicios
El primer objetivo de toda migración es conseguir una transición de un sistema

a otro sin que los usuarios noten ninguna gran diferencia o, a ser posible,
ninguna diferencia en absoluto. Una estrategia para conseguir este objetivo es
empezar la migración en los servidores, de manera que los usuarios puedan
continuar trabajando normalmente hasta que el sistema esté preparado para
la migración de los clientes.
Entre los servicios que se pueden migrar fácilmente al inicio hay los de red
(DNS, DHCP, etc.), los servidores web y los servidores de bases de datos. Puede
ser necesario el uso de soluciones tecnológicas que funcionen bien en sistemas
heterogéneos, como OpenLDAP combinado con Samba.
De esta manera se dispone también de bastante tiempo para formar al personal

técnico, el apoyo del cual puede ser muy útil a la hora de migrar los clientes
y dar soporte al resto de usuarios.
Tanto la introducción de aplicaciones puente como la migración escalonada

de servicios se tendrán que tener en cuenta en la planificación del proyecto.
2.8.3. Comunicación del proyecto
Como se ha visto, la implantación y migración a un sistema basado en software

libre es un proceso que implica a todos los usuarios de la organización, y no
sólo al personal técnico encargado de su despliegue y mantenimiento.
Es esencial disponer de mecanismos eficaces de comunicación entre los usua-

rios y la dirección técnica y administrativa de la organización y garantizar la
transparencia de todo el proceso, por lo que las actividades de comunicación
tienen que estar definidas en el plan de proyecto, que tiene que incluir:
• Comunicación�inicial�conjunta�a�todos�los�usuarios. Se explicará la mo-

tivación y la planificación general del proyecto antes de su puesta en mar-
cha a través de reuniones informativas, notas o correos electrónicos inter-

nos o anuncios en la intranet de la organización.
• Comunicación�periódica�del�avance�del�proyecto. Se indicarán qué par-

tes del sistema se migrarán y cuándo, así como las eventuales modifica-
ciones del proyecto. Se organizarán reuniones reducidas con los usuarios
implicados en cada una de las fases de la migración.
• Reuniones�periódicas�después�de�la�finalización�del�proyecto. Se eva-
luará el éxito del proyecto y se hará un seguimiento general de sus resul-
tados, así como de las experiencias de los usuarios del sistema.
2.8.4. Sistema de soporte al usuario
Un pilar fundamental del nuevo sistema es la puesta en funcionamiento de

un sistema de gestión de incidencias a disposición de los usuarios, de manera
que puedan resolver tanto sus dudas como los problemas técnicos derivados
de la situación. Es importante dar una respuesta rápida y eficaz a todos estos
problemas, sobre todo en los primeros momentos después de la implantación.
A la hora de diseñar un sistema de soporte al usuario, hay que responder estas

preguntas, que definirán las características principales del sistema:
• ¿Quiénes son los usuarios?

• ¿Cómo funciona la organización?
• ¿Qué tipo de soporte necesitan los usuarios?
• ¿Qué tipo de soporte se ofrecerá a cada tipo de usuario?
• ¿Cuánto soporte se ofrecerá?
• ¿Cómo se ofrecerá el soporte?
La realización de pruebas piloto puede servir como base para caracterizar la

mayoría de los problemas con que se encontrarán los usuarios, y así preparar
un procedimiento para resolver cada uno de ellos.
De la misma manera, se tendrán que identificar los servicios y los usuarios más
importantes y críticos del sistema, que disfrutarán de un soporte preferente.
Por otra parte, hay que tener en cuenta que más soporte representa un coste
más elevado. Está la posibilidad de sobredimensionar el soporte en las prime-
ras semanas después de la migración, cuando el número de consultas y de in-
cidencias sea mayor. En cualquier caso, la clave para que un sistema de soporte
al usuario sea eficaz es garantizar una comunicación fluida con los usuarios,
de manera que éstos sean conscientes de que su problema se tiene en cuenta.
Finalmente, es posible que antes de la migración ya existiera un sistema de Página web

soporte al usuario. En caso de que este sistema estuviera basado en software
Existen numerosas solu-
propietario, habría que evaluar las diferentes alternativas libres disponibles. ciones. Se puede consul-
tar una comparación en
http://en.wikipedia.org/wi-
ki/Comparison_of_ticket-
tracking_systems.
3. La empresa del software libre
Esta tercera unidad de la asignatura de "Implantación de sistemas en software

libre" proporciona las bases para conocer los principales conceptos y caracte-
rísticas ligados al negocio empresarial del software libre.
Desde sus inicios, el software libre siempre ha estado presente a nivel de las Ved también
tecnologías de la información. Su evolución a lo largo del tiempo se ha visto
Con el fin de conocer más as-
influida por los cambios estructurales que se han ido produciendo a nivel tec- pectos históricos del softwa-
nológico, económico y social. re libre, consultad el segundo
punto de los materiales de la
asignatura de "Introducción al
software libre".
Con el paso del tiempo, se han puesto de manifiesto las diferentes filosofías en
torno a la creación, producción y difusión del software. En términos generales,
hay que destacar dos tendencias principales con características opuestas:
• Por un lado, la filosofía propietaria, que defiende la protección del software

con el cierre y privatización del código fuente, así como la imposición de
licencias con fuertes restricciones para su utilización.
• Por otra parte, la filosofía libre, que defiende la libertad del software y del
código fuente con licencias que garantizan los derechos de los usuarios en
la ejecución del programa, el estudio y la adaptación del código fuente y
la redistribución y la publicación de las mejoras que se puedan introducir.
Estas dos filosofías han generado modelos de negocio empresarial opuestos en

la ideología, el funcionamiento, la operativa y la economía:
• El modelo de software privativo normalmente establece un valor econó-

mico que hay que sufragar mediante el uso restringido de una copia en
formato binario, hecho que imposibilita la adaptación, corrección o me-
jora del código fuente por parte de personas u organizaciones que no dis-
ponen de los derechos de autoría, o del acuerdo explícito de los que los
poseen. Hay que destacar que muchas licencias propietarias impiden ce-
der los derechos de utilización a un tercero sin el previo acuerdo de los
poseedores de los derechos de autoría.
• El modelo de software libre tiende a centrarse en el desarrollo y la adapta-

ción de soluciones libres y cualitativas que respondan a las necesidades de
usuarios y organizaciones, así como los servicios complementarios para su
puesta en marcha y funcionamiento habitual. En este sentido, el modelo
de negocio basado en el software libre permite las actuaciones que impide
o restringe el modelo de software privativo.
La particular concepción filosófica del software libre no sólo influye directa-

mente en el modelo de negocio y en la estrategia empresarial, sino también
en la definición, la gestión, la organización y el funcionamiento de la empre-
sa tecnológica. Aspectos como la madurez del software libre, la presencia de
una comunidad mundial de colaboradores en proyectos de software libre y
la viabilidad de los modelos de negocio reconfiguran el proyecto empresarial
clásico de forma sustancial.
El primer apartado de esta unidad se dedica a caracterizar a los diferentes mo-

delos de negocio basados en el software libre, válidos y viables para ser lleva-
dos a la práctica como estrategia empresarial.
El segundo apartado se dedica íntegramente a la concepción del plan de ne-

gocio empresarial y se detallan los principales aspectos ligados a la creación,
organización, producción y funcionamiento de la empresa del software libre.
El tercer apartado presenta la producción de software libre, con la caracteriza-

ción de las principales particularidades en la creación, organización, comuni-
cación y desarrollo del código fuente.
Finalmente, esta unidad dispone de dos anexos en los cuales se presentan de

forma breve y sistemática las principales licencias libres y estándares abiertos
que tienen relación directa con el negocio del software libre.
3.1. Modelos de negocio
En este primer apartado se presentan los principales modelos de negocio ba-

sados en el software libre, así como las características y particularidades que lo
diferencian de las tendencias de negocio basadas en software propietario.
En general, la diferencia más significativa entre el software libre y el

privativo desde el punto de vista empresarial es la licencia. A grandes
rasgos, una licencia es un modelo contractual en el cual el autor del
producto (o aquél que posee los derechos de autoría) establece los de-
rechos y deberes de los usuarios del producto y el escenario en el cual
los pueden utilizar.
(35)
En este sentido, las licencias libres35 se basan en cuatro principios básicos de Existe una cierta controver-
sia entre la Free Software Foun-
libertad con respecto al software y su código fuente: dation (http://www.fsf.org) y la
Open Source Initiative (http://
www.opensource.org) a causa de
• La libertad de ejecutar el programa con cualquier propósito. las implicaciones de los términos li-
bre y abierto.
• La libertad de estudiar el código fuente y adaptarlo a las necesidades par-

ticulares, por lo cual es necesario el acceso al código fuente.
• La libertad de redistribuir copias del software. Recurso web
Encontraréis la definición
• La libertad de mejorar el software y publicar las mejoras, por lo cual es original de software libre en
necesario el acceso al código fuente. http://www.gnu.org/philo-
sophy/free-sw.html.
Los principios básicos de libertad del software libre se contraponen al modelo

(36)
privativo centrado en la explotación comercial de venta de licencias de utiliza- En inglés, right-to-use licensing.
36
ción 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 organización que lo gestiona.
Descargas directas y gratuitas
Unos ejemplos de descargas directas y gratuitas:
• Debian GNU/Linux de http://www.debian.org/distrib/

• FreeBSD de http://www.freebsd.org/where.html
• KOffice de http://www.koffice.org/download/
• OpenOffice.org de http://download.openoffice.org/
La apertura filosófica del software libre favorece los modelos de negocio cen-
trados en el capital humano, los conocimientos, la personalización y la ade-
cuación de los productos, así como la evolución constante del software. En es-
te sentido, es importante destacar el papel que juega la comunidad de usuarios
del software libre, que vela por la calidad y por la evolución de los productos
libres, con un rendimiento difícilmente igualable en modelos de propiedad.
Con el tiempo, el modelo del software libre ha consolidado una oferta que Recursos web
abarca la mayoría de sectores con presencia de software privativo, y ofrece un
En http://freshmeat.net/ y
mercado maduro, cualitativo y seguro sobre el cual basar una estrategia em- http://sourceforge.net/ en-
presarial, tanto para el desarrollo de software como para los servicios comple- contraréis un amplio abanico
de proyectos de software li-
mentarios. bre en las principales áreas de
aplicación de la tecnología.
En cierta manera, la estrategia de negocio del software libre se funda-

menta en los aspectos diferenciadores con respecto al modelo de pro-
piedad, por ejemplo la ampliación de funcionalidades, la adaptación
personalizada, el elevado y constante número de revisiones, las garan-
tías de seguridad y calidad de funcionamiento del producto, así como
todo un abanico de servicios complementarios para la puesta en marcha
y el funcionamiento habitual.
En los siguientes apartados se presentan los principales modelos de negocio

que se derivan de la filosofía conceptual del software libre: desarrollo, consul-
toría, instalación e integración, migración, mantenimiento y soporte y forma-
ción.
Los modelos de negocio que se presentan no deben entenderse como inde-

pendientes, sino como complementarios. Es decir, puede convenir la combi-
nación de dos o más modelos de negocio para dar respuesta a la estrategia
empresarial.
3.1.1. Desarrollo
El modelo de negocio de desarrollo de software se basa en la producción

total o parcial de un producto basado en software libre destinado a su
comercialización, ya sea directamente o bien en el marco de un proyecto
de implantación por cuenta ajena, como los presentados en la segunda
unidad de la asignatura.
La definición de software libre no hace ninguna referencia con respecto a la

estrategia de vender un producto libre a un precio por copia vendida, pero las
características de las licencias libres convierten esta posibilidad en una opción
secundaria, aunque sobradamente utilizada por algunas organizaciones.
Productos libres empaquetados
Algunas organizaciones deciden ofrecer sus productos libres empaquetados (caja, discos,
manuales, documentación, etc.) a cambio del abono de un importe que, a pesar de ser
inferior al precio de soluciones alternativas, es superior al precio de coste. Por ejemplo, se
puede comprar la distribución Ubuntu en http://www.ubuntu.com/getubuntu/purchase.
En general, la producción de software libre responde principalmente a la venta

de servicios complementarios de valor añadido para el cliente, que también
sirven para sustentar la continuidad del software, por ejemplo la personaliza-
ción y adecuación a un entorno determinado.
En los materiales de la asignatura de "Introducción al software libre" se ofrece Ved también

una clasificación de las posibles alternativas del desarrollo de software libre,
Encontraréis más información
reproducida brevemente a continuación: y ejemplos de esta clasificación
en el apartado 5.2 "Modelos
de negocio basados en softwa-
• Mejor� conocimiento. Se basa en el propósito de rentabilizar el conoci- re libre" de los materiales de la
asignatura de "Introducción al
miento sobre uno o más productos libres, ofreciendo desarrollos a medida, software libre".
modificaciones o adaptaciones (entre otros que se presentarán más ade-
lante). La participación activa en la creación y desarrollo de los productos
libres es el valor añadido de la empresa ante el cliente y la competencia.
• Mejor� conocimiento� con� limitaciones. Se basa en el modelo anterior

(mejor conocimiento) pero con una implementación mixta de licencias
libres y de propiedad (o eventualmente patentes) para reducir la compe-
tencia. Este modelo puede resultar inviable si el producto libre se escinde

en una rama soportado por la comunidad libre, de manera que podría de-
saparecer la ventaja competitiva.
• Fuente�de�un�producto�libre. Es similar al primer modelo (mejor conoci-

miento) con la diferencia que la empresa es la productora del código de
forma casi íntegra. El cliente valora el posicionamiento y la ventaja com-
petitiva con respecto a la competencia. Este modelo recibe el soporte de
la comunidad libre.
• Fuente�de�un�producto�con�limitaciones. Se basa en el modelo anterior

(fuente de un producto libre) pero con una implementación orientada a
reducir la competencia, por ejemplo iniciando la distribución bajo licencia
privativa y liberándose más adelante, o haciendo que la distribución inicial
se limite a los clientes de la empresa.
• Licencias�especiales. Se basa en la producción de un mismo producto que

se distribuye bajo diferentes licencias, libres y propietarias. El producto de
propiedad se orienta a implementaciones especiales del producto, como
la integración con otros productos propietarios.
• Venta�de�marca. Se basa en la distribución de productos libres con una

imagen de marca empresarial, que da calidad y valor añadido desde el pun-
to de vista del cliente. Normalmente, estos productos se acompañan de
numerosos servicios adicionales a los clientes.
La selección de la tipología de negocio asociada al desarrollo de software tie-

ne que coordinarse principalmente con la estrategia empresarial y el mercado
objetivo. En este sentido, una organización puede decidir usar una tipología
personalizada para cada uno de los productos que pretenda introducir en el
mercado, en función de la estrategia y el mercado objetivo particular que per-
siga en cada uno de ellos.
El modelo de negocio de desarrollo de software libre también exige la selección

esmerada de las licencias del código fuente que manipula:
• La licencia del código fuente que modifica, si el producto final es una me-
jora de un producto que ya existía antes.
• La licencia del código fuente que enlaza, si el producto final requiere para
su operativa implementar llamadas en funciones de bibliotecas externas.
• La licencia del código fuente que crea, es decir, cuando el código fuente
es completamente nuevo.
• La licencia del código fuente del producto final, que considera el conglo-
merado de código fuente del producto final.
La importancia de determinar esmeradamente la licencia asociada a cada parte

del código fuente que se manipula radica en la existencia de diferencias entre
las diversas licencias libres. Es decir, aunque todas las licencias libres garanti-
zan las cuatro libertades básicas, difieren en la política de licenciamiento de
la redistribución de código modificado, que es precisamente el objeto del mo-
delo de negocio de desarrollo de software libre.
En el anexo I de esta unidad presentamos brevemente las características más

importantes de las principales licencias del software libre y exponemos la po-
lítica de redistribución y las compatibilidades del enlace y de la obra derivada.
La selección y combinación adecuada de licencias influye directamente en

la producción de software libre, y puede tener implicaciones legales si no se
realiza esmeradamente. En el último apartado de esta unidad, dedicado a la
producción de software libre, se profundizará en la selección de la licencia más
adecuada a partir de los parámetros del producto.
Finalmente, hay que decir que el software libre promueve y utiliza especifi-
caciones públicas, denominadas estándares abiertos, con el fin de favorecer
la universalidad y la interoperabilidad de los formatos que manipulan. En el
anexo II de esta unidad didáctica presentamos brevemente las principales ca-
racterísticas y ejemplos de los estándares abiertos.
3.1.2. Consultoría
El modelo de negocio de consultoría se basa en la producción de ser-

vicios profesionales complementarios al software libre para usuarios y
organizaciones.
En cierta manera, este modelo de negocio se centra en el objetivo de proveer Ved también
servicios tecnológicos profesionales externos de calidad a organizaciones que
En el apartado "Clasificación
no asumen totalmente la creación, la gestión, el desarrollo y la evaluación de por ámbito" de la primera uni-
sus proyectos tecnológicos internos. dad encontraréis más informa-
ción de la tipología de proyec-
tos productivos.
La diversidad de servicios profesionales que pueden ofrecer las consultorías es
elevado, y dependerá de la estrategia y el entorno a actividad empresarial. Sin
embargo, tienen una fuerte relación con las actividades de estudio, análisis,
diseño y evaluación propias del proyecto de implantación de sistemas de soft-
ware libre presentado en la segunda unidad de este módulo.
A continuación, presentamos una clasificación breve de los principales servi-

cios que una consultoría puede ofrecer a sus clientes:
• Gestión� de� proyectos: se basa en el propósito de realizar las funciones Ampliando información
de creación y gestión funcional del proyecto de implantación de software
En el apartado "Tipologia de
libre. Las tareas que desarrolla este servicio se relacionan con el ciclo de proyectos" de la primera uni-
vida del proyecto, la gestión de los equipos de profesionales involucrados dad y en el apartado "Ciclo de
vida" de la segunda unidad en-
en cada etapa del proyecto, el control del progreso efectivo del proyecto y, contraréis más información so-
bre la gestión y el ciclo de vida
en general, todas aquellas tareas de coordinación, información, gerencia de los proyecto de software li-
y seguimiento del proyecto. bre.
• Ejecución�de�etapas�de�análisis�y�diseño�del�proyecto: se basa en el pro- Ved también

pósito de realizar una o más etapas de análisis y diseño del proyecto de
En los apartados "Estudio de la
implantación de un sistema en software libre. Las tareas que desarrolla es- situación actual", "Estudio de
te servicio se relacionan con los encargos de la contratación, por ejemplo los requisitos de la implanta-
ción", "Análisis de las solucio-
el estudio del sistema actual, el estudio de requerimientos del nuevo siste- nes en software libre" y "Desa-
rrollo" de la segunda unidad
ma, el análisis de soluciones en software libre y/o el diseño de un nuevo encontraréis más información
sistema, de acuerdo con las etapas presentadas en la segunda unidad del sobre el estudio del sistema
actual, el estudio de requeri-
módulo. mientos del sistema, el análi-
sis de las soluciones en softwa-
re libre y el diseño del sistema,
• Evaluación�y�auditoría: se basa en el propósito de realizar valoraciones respectivamente.
tecnológicas profesionales de una o más características de sistemas en fun-

cionamiento. Las tareas que desarrolla este servicio pueden estar enmarca-
das dentro de un proyecto de implantación de sistemas, como sería el ca-
so de la ejecución de etapas visto anteriormente, pero también se pueden
desarrollar de forma independiente y aislada. La evaluación o la auditoría
se centra en valorar uno o más aspectos del sistema, como la seguridad,
el rendimiento, la eficiencia o la eficacia (entre otros), y se puede realizar
antes y/o después de la implantación del sistema.
• Asesoría: se basa en el propósito de dar soporte, ayuda y consejo profe-

sional a la toma de decisiones tecnológicas en la organización. Las tareas
que desarrolla pueden tener lugar antes del inicio de cualquier proyecto
de implantación o bien en las fases de estudio, análisis y diseño, pero se
enmarcan en el soporte profesional a decisiones estratégicas tecnológicas
para el futuro de la organización.
La lista presentada no se tiene que considerar ni exhaustiva ni excluyente, ya

que el modelo de negocio puede estructurar dos o más servicios para responder
a la estrategia empresarial. Adicionalmente, el modelo de negocio de consul-
toría puede combinarse con otros modelos de negocio para ofrecer al cliente
un servicio tecnológico integral.
En este sentido, el mejor conocimiento de las plataformas tecnológicas im-

plantadas (o que hay que implantar), así como la excelencia para el análisis y
extracción de información y conclusiones, o el alcance y la complejidad del
proyecto, son características decisorias a fin de que la organización decida ex-
ternalizar la gestión o las etapas de la implantación.
Normalmente, los trabajos de consultoría se formalizan con contratos abiertos

o cerrados. En los contratos abiertos la relación se origina a partir del encargo
de un servicio determinado y, en función del resultado del servicio, el contrato
se amplía con el encargo de nuevos servicios. Por ejemplo, la ejecución de una
o más etapas del proyecto puede estar sujeta a contratos abiertos.
En cambio, en los contratos cerrados se adjudica el cumplimiento de un de-

terminado objetivo, función, resultado o trabajo, sin posibilidad directa de
ampliar la contratación en el mismo escenario. Por ejemplo, la auditoría in-
dependiente de un sistema puede estar sujeta a contratos cerrados, dadas las
eventuales características temporales de puntualidad y aislamiento.
3.1.3. Instalación e integración
El modelo de negocio de instalación e integración se basa en la implan-

tación directa de sistemas en software libre para usuarios y organizacio-
nes, normalmente enmarcados en proyectos de software libre.
En cierta manera, este modelo de negocio considera el software libre como

objeto para la producción de servicios, más que como producto en sí mismo.
De esta forma, se fundamenta un mercado en el cual se resaltan los beneficios
para el cliente:
• La organización no tiene que pagar licencias en productos de software libre

que se distribuyen de forma gratuita y, por consiguiente, puede reducir el
coste de implantación tecnológica.
• La organización no tiene que recurrir a la piratería de productos y, por

consiguiente, no incumplirá la legalidad vigente.
• La organización puede adaptar directamente las soluciones libres y, por

consiguiente, podrá disminuir el coste de implantación de sistemas espe-
cializados.
• La organización puede adoptar paquetes integrados de implantación di-

recta y, por consiguiente, reducirá el riesgo de implantación tecnológica.
A continuación presentamos una lista breve de los principales servicios que

puede ofrecer este modelo de negocio, aunque la lista no es exhaustiva ni
excluyente de otros servicios:
(37)
• Configuración: se trata de realizar las tareas de configuración y ajuste37 de En inglés, set-up o tune-up.
un sistema ya implantado con el objetivo de formalizar la configuración

inicial, mejorar su rendimiento o ajustarlo a nuevos propósitos no consi-
derados inicialmente. En cualquier caso, los ajustes que se introducen no
modifican el código fuente de la aplicación, únicamente la configuración
de aquellos componentes que permitan el ajuste a las características par-
ticulares de la instalación.
• Pruebas: se trata de proporcionar un banco de pruebas de sistemas, apli- Ampliando información

caciones o soluciones en software libre bajo una perspectiva determinada.
En los apartados "Análisis de
Puede tratarse de un análisis comparativo de soluciones libres, las pruebas las soluciones en software li-
de un nuevo diseño de sistema, o el test de software de implantación di- bre", "Desarrollo" e "Implanta-
ción y migración" de la segun-
recta sobre hardware específico, ya sea en el marco de un proyecto de im- da unidad encontraréis más in-
formación sobre el análisis de
plantación, o bien como pruebas independientes y aisladas. las soluciones en software li-
bre, el diseño del sistema y la
implantación y migración del
• Integración: se trata de realizar y/o comprobar la integración entre dos o sistema, respectivamente.
más soluciones de software libre, con el objetivo de proporcionar un pa-

quete único que resuelva una función operativa concreta38. Normalmente, (38)
Por ejemplo, LAMP (Linux, Apa-
esta integración se puede resolver con la configuración apropiada de cada che, MySQL, PHP) es un paquete
integrado de software con diferen-
elemento y, eventualmente, con algún componente adicional que permita tes objetivos particulares, pero que
conjuntamente soluciona una pro-
la integración con más eficiencia. blemática concreta de forma efi-
ciente y eficaz.
(39)
• Instalación: se trata de realizar la instalación masiva de software de im- En inglés, sería similar al térmi-
39 no installfest, pero aplicado al ne-
plantación directa en máquinas clientes o servidores . Este servicio pue- gocio estructurado.
de necesitar la configuración y el ajuste tanto del software libre que se
pretende instalar como del hardware receptor de la instalación. También
puede ser necesaria la integración de las diferentes soluciones que se pre-
tenden instalar. En los casos en los cuales se tenga que implantar el mismo
software en un conjunto de ordenadores con idéntico hardware, puede
resultar útil usar software de clonado y distribución de imágenes precon-
figuradas para ahorrar tiempo y coste, además de mejorar la eficiencia y
eficacia del proceso.
(40)
• Distribución: se trata de redistribuir software libre a los clientes, ya sea en En http://freshmeat.net/ y
40 http://sourceforge.net/ encontra-
el format original o bien en configuraciones personalizadas en relación réis un amplio abanico de proyec-
con el ámbito de negocio empresarial; por ejemplo la integración de he- tos de software libre en las princi-
pales áreas de aplicación de la tec-
rramientas, la orientación operativa a cliente, a servidor o a estación de nología.
trabajo41, entre otros. La redistribución de software integrado está sujeta a

(41)
las licencias de las soluciones particulares. En el anexo I se presentan las En inglés, workstation.
principales licencias de software libre y su compatibilidad.

Tal como se desprende de la clasificación anterior, estos servicios tienen una

fuerte relación con las etapas de análisis de las soluciones en software libre y
de implantación y migración del proyecto de implantación presentado en la
segunda unidad. En este sentido, el mejor conocimiento de las plataformas
tecnológicas, así como la excelencia y eficiencia de los servicios, o el alcance
y la complejidad del proyecto, son características decisorias a fin de que la
organización decida externalizar la instalación y la integración del sistema.
3.1.4. Migración de sistemas
El modelo de negocio de migración de sistemas se basa en el hecho de

trasladar la operativa de funcionamiento entre el sistema implantado y
el nuevo sistema que hay que implantar.
La migración es un proceso complejo, que hay que ejecutar con la precisión

y el rigor necesarios de acuerdo con la importancia que suponen los datos y
configuraciones como capital para la organización.
La diversidad de situaciones con que se pueden encontrar las empresas que

se dedican a la migración de sistemas son fruto de la combinación entre las
plataformas de origen y de destino de la migración. El conocimiento profun-
do de las plataformas y la experiencia en la migración fundamentan el valor
añadido para el cliente.

ofrece este modelo de negocio, aunque la lista no es exhaustiva ni excluyente
de otros servicios:
Ved también
En el apartado "Implantación y migración" de la segunda unidad encontraréis sobrada-

mente detalladas las características de la migración de sistemas. Concretamente, en el
apartado "Migración de los servicios de un sistema" encontraréis más información de los
servicios que aquí presentamos.
• Servicios de sistema de ficheros, tanto de servidor como de clientes.
• Servicios de impresión, tanto entre clientes como entre servidores.
• Servicios de directorio y de autentificación centralizada.
• Servicios de red, especialmente de protocolos de gestión automatizada de

control de la red, de las comunicaciones y de los clientes.
• Gestión y administración del sistema, tanto la gestión de la red como del

software.
• Servicios web, tanto con plataformas estáticas como dinámicas.
• Bases de datos, tanto la migración de los datos como la verificación de los

accesos.
• Entornos de escritorio y aplicaciones de ofimática, tanto las aplicaciones

como los datos de usuario.
• Aplicaciones corporativas, tanto las aplicaciones que se pueden ejecutar

directamente, como las que exigen ajustes o virtualizaciones.
La complejidad y el alcance de la migración, la capacidad de realizar el proceso

de forma esmerada, eficiente, eficaz y con el menor tiempo posible, así como el
mejor conocimiento de las plataformas tecnológicas de origen y de destino de
la migración son características decisorias a fin de que la organización decida
externalizar la migración del sistema.
Tal como se puede concluir de la clasificación de los servicios que hemos pre-
sentado, el proceso de migración puede necesitar otros servicios, como la ins-
talación, la configuración, la integración o las pruebas para asegurar la conse-
cución de los objetivos.
El software libre utiliza y fomenta los estándares abiertos para el intercambio

interoperable de los datos y es especialmente relevante su papel en la migra-
ción de los sistemas. Por ejemplo, partir de un sistema que no almacene los
datos en estándares abiertos podría complicar la migración a causa de la con-
versión de los formatos, especialmente si el original es privativo. En el anexo
II de este módulo didáctico presentamos los estándares abiertos, su definición,
los organismos que los impulsan y algunos ejemplos.
3.1.5. Administración y mantenimiento de sistemas
El modelo de negocio de administración y mantenimiento de sistemas

se basa en realizar las tareas de gestión y seguimiento de un sistema ya
implantado y en funcionamiento.
El principal objetivo de los servicios que puede ofrecer este modelo de nego-
cio es mantener funcional todo el sistema a lo largo del tiempo, ajustando la
configuración a los cambios que se produzcan, solucionando problemáticas
que puedan surgir y reparando las averías que impidan el funcionamiento ha-
bitual de la organización.

de otros servicios:
(42)
• Administración: consiste en proporcionar la gestión principal del siste- Por ejemplo, el uso conjunto de
ssh, cron y at.
ma, el ajuste necesario con el paso del tiempo, la supervisión del funcio-
namiento, la implantación de nuevas funcionalidades y la evolución del
sistema. Muchas de las tareas de administración del sistema se pueden eje-
42
cutar de forma remota .
• Mantenimiento� y� evolución: consiste en proporcionar supervisión, se-

guimiento y corrección de las incidencias que se puedan originar en el
sistema y que impidan su funcionamiento, así como el control y evolu-
ción de la obsolescencia de los componentes. Por ejemplo, las averías y la
desconfiguración de hardware o de software, el control y actualización de
versiones de software, o el plan de evolución de hardware y software.
• Seguridad: consiste en proporcionar la gestión de la seguridad del sistema,

controlando los riesgos, manteniendo políticas de prevención, contingen-
cia, diagnóstico y corrección de fallos. Por ejemplo, copias de seguridad o
el control y mantenimiento de claves y certificados.
Dadas las características y particularidades de estos servicios, muchas organi-

zaciones deciden mantener trabajadores en plantilla que realicen estas tareas,
pero algunas organizaciones pequeñas o medias no tienen bastante capacidad
para asumir esta figura.
También hay que tener en cuenta que la externalización de algunos servicios, Intranet y extranet
como servidores de intranet y de extranet, pueden motivar la contratación de
Los servicios web, de intranet
servicios externos de administración y mantenimiento. Normalmente, estos o de extranet son fácilmente
servicios funcionan con contratos con cuota fija mensual o anual para una externalizables gracias a la pro-
liferación de los hoteles de da-
determinada cobertura de servicios. tos (Data Hotels) o centros de
datos (Data Centers).
3.1.6. Soporte y formación
El modelo de negocio de soporte y formación consiste en proporcionar

ayuda técnica profesional para la educación y aprendizaje tecnológico
de usuarios y la resolución de incidencias y problemas relacionados con
la explotación del sistema.
La implantación de sistemas en software libre puede necesitar medidas de so-

porte y formación a los usuarios durante los primeros momentos de utiliza-
ción, especialmente si el sistema anterior estaba basado en software privativo.
Tal como se ha visto en el segundo módulo de la asignatura, el proyecto de
implantación tiene que tener en cuenta la necesidad de actuar en el aprendi-
zaje de los usuarios para favorecer la gestión del cambio, el cual, junto con sus
particularidades, hace que acabe siendo un servicio fácilmente externalizable
a empresas especializadas en este sector.

de otros servicios:
• Formación: se propone proporcionar educación y aprendizaje sobre he- Ved también

rramientas de software libre a usuarios finales, por ejemplo sistemas ope-
En el apartado "Formación, co-
rativos o herramientas de ofimática. Este servicio también puede incluir municación y soporte al usua-
la formación de software especializado resultante del desarrollo producido rio" de la segunda unidad en-
contraréis más información so-
en el proyecto de implantación de sistemas, por lo que puede resultar con- bre la formación y el soporte al
usuario.
veniente para la gestión del cambio coordinar los esfuerzos con el equipo
de implantación.
(43)
• Soporte: se propone proporcionar asistencia técnica a los usuarios ante En inglés, call centers.
problemas cotidianos. Muchos de estos servicios se implementan en cen-
(44)
tros telefónicos de ayuda43, aunque también puede resultar útil ofrecer bu- En inglés, instant messaging o
chat.
zones de correo electrónico para la resolución de incidencias o mensaje-
ría instantánea44 con un profesional. También puede resultar convenien-
te combinar los esfuerzos con el equipo del proyecto de implantación de
sistemas con el fin de resolver posibles errores del software implantado.
En general, este modelo de negocio pide recursos humanos, tecnológicos y

materiales adecuados a los objetivos de la formación:
• Recursos humanos con conocimientos profundos de la temática y con ca- Recurso web
pacidad para transmitir los conocimientos y resolver problemas.
Por ejemplo, Moddle es una
plataforma de educación a
• Recursos tecnológicos adecuados a la formación y el soporte, por ejemplo distancia basada en software
libre. http://moodle.org/.
plataformas tecnológicas de ayuda a la educación o centros telefónicos de
asistencia técnica.
(45)
• Recursos materiales adecuados a la formación, como documentación y ma- El proyecto SELF proporciona
45 una plataforma europea para crear
nuales específicos de software libre bajo licencias libres. y compartir materiales educativos
relacionados con el software libre
y los estándares abiertos (http://
La calidad de estos parámetros es fundamental a fin de que la organización selfproject.eu/).
decida externalizar los servicios de formación y soporte. Normalmente, los
servicios de formación se contratan por cursos con estructura acordada pre-
viamente, mientras que los servicios de soporte se contratan por cuotas men-
suales o anuales, con acuerdo previo de los servicios cubiertos.
3.2. Plan de empresa Ved también
En el apartado 10.2 "Licencias

de otros recursos libres" del
Un plan de empresa o de negocio es un instrumento que identifica, material de la asignatura de
Introducción al software libre
describe y analiza una oportunidad de negocio, examina su viabilidad encontraréis dos licencias de
y desarrolla los procedimientos y estrategias para crear la empresa que documentación, materiales y
obras literarias sobradamente
explote la oportunidad de negocio. utilizadas en la actualidad.
Aclaración
En este apartado se utilizará preferentemente el término plan de empresa, ya que el ob-

jetivo del apartado es presentar los elementos necesarios para la creación de una empresa
de software libre, como la ilustrada en el caso Cometa Technologies, que se verá en el
segundo apartado.
De acuerdo con esta definición, los objetivos del plan de empresa son los si-
guientes:
• Realizar un estudio de mercado que posicione el proyecto empresarial y

determine su viabilidad técnica, económica y financiera
• Desarrollar las medidas necesarias para conseguir los objetivos fijados en

el mismo plan de empresa
• Realizar un seguimiento de la evolución de la empresa y evaluar las des-

viaciones respecto al plan de empresa inicial
• Servir como tarjeta de presentación del proyecto y de los emprendedores

a fin de obtener financiación y apoyo de terceros
Si bien los tres primeros objetivos son principalmente de uso interno, el últi-
mo es de uso externo y visible por personas ajenas al proyecto, al menos en
principio. Durante la preparación de un plan de empresa hay que tener en
cuenta siempre esta doble finalidad: servir como plan de proyecto y, a la vez,
como presentación del proyecto.
Por supuesto, hay que evitar la tentación de omitir los riesgos o aspectos ne-
gativos del proyecto a fin de hacerlo más atractivo a los inversores. De hecho,
la falta de estos elementos podría volverse en contra del propio proyecto em-
presarial, ya que estaría basado sobre supuestos falsos. Por ello, la veracidad de
los aspectos técnicos y económicos es uno de los requisitos básicos a la hora
de redactar un plan de empresa.
Todo plan de empresa debe responder a una serie de preguntas sobre el proyec-
to que se desea poner en marcha: ¿quién?, ¿qué?, ¿por qué?, ¿dónde?, ¿cuán-
do? y ¿cuánto?
• ¿Quién?
El nombre de la empresa, la marca de los productos o servicios ofrecidos,
los nombres y trayectoria de los promotores.
• ¿Qué?
La descripción de los productos o servicios ofrecidos, los mercados a los
que se dirigen y la cuota de mercado que se fija como objetivo, entre otros.
• ¿Por�qué?
En general, todo plan de empresa busca obtener y maximizar los beneficios
económicos. Sin embargo, esto no es incompatible con otros objetivos
como la mejora de la calidad de vida de la sociedad o la creación de empleo.
• ¿Dónde?
La zona geográfica en la que se van a comercializar los productos o servi-
cios, por ejemplo regional, nacional o internacional. Los canales de distri-
bución que se van a utilizar, incluyendo los posibles acuerdos con otras
empresas que permitan acceder a otras regiones.
• ¿Cuándo?
El inicio previsto de la actividad empresarial y su planificación posterior,
incluyendo condiciones o limitaciones temporales que puedan afectar a
la empresa, como los trámites de obtención de licencias, el tiempo de pro-
ducción, la obsolescencia de determinadas tecnologías o la estacionalidad.
• ¿Cuánto?
La inversión inicial necesaria para poner en marcha el proyecto empresa-
rial, la facturación mínima necesaria y la deseada, el umbral de beneficios
y pérdidas, la reinversión de los beneficios y la repartición de dividendos,
entre otros.
Estas cuestiones se traducen en los siguientes aspectos que se encuentran en

casi todo plan de empresa:
• Resumen ejecutivo
• Introducción
• Descripción del negocio
• Organización de la producción
• Organización interna y recursos humanos
• Estudio de mercado
• Plan de marketing
• Análisis económico-finaciero
• Forma legal
• Gestión de riesgos
• Resumen y evaluación
Dependiendo de la naturaleza de la empresa o negocio cada uno de estos as-

pectos tendrá mayor o menor importancia en el plan de empresa y podrá or-
ganizarse de diferentes maneras.
En los apartados que veremos a continuación se revisará cada uno de estos

aspectos y se estudiará su relación con los modelos de negocio basados en
software libre vistos en el apartado anterior.
3.2.1. Resumen ejecutivo
(46)
En cualquier caso, su extensión
46
El resumen o sumario ejecutivo es una nota breve que aparece al prin- no debería superar las tres páginas.
cipio del plan de empresa y que resume los elementos principales del
documento. De esta manera, permite que por ejemplo potenciales in-
versores puedan hacerse una idea completa del plan de empresa, sin
necesidad de entrar en los detalles de cada uno de los apartados.
El resumen ejecutivo debe repasar prácticamente todos los aspectos del plan
de empresa, a saber:
• Descripción del modelo de negocio, prestando especial atención a la ca-

dena de valor y la fuente de ingresos.
• Breve descripción del los promotores del proyecto, su formación, sus co-
nocimientos y habilidades, su trayectoria profesional y su dedicación al
nuevo proyecto.
• Descripción concisa del mercado, incluyendo tamaño, clientes, potencial

de crecimiento y barreras.
• Análisis de las áreas funcionales del proyecto: producción, calidad y orga-

nización de los recursos humanos.
• Resumen del análisis financiero del proyecto y de la inversión necesaria

para su puesta en marcha.
• Resumen de los riesgos asociados al proyecto y los planes para prevenirlos

y remediarlos.
Resulta obvio que el resumen ejecutivo debe destacar los puntos fuertes del
plan de empresa, especialmente en lo que se refiere al modelo de negocio que
se desea desarrollar, la estrategia que se va emplear para ello y el equipo pro-
motor.
Se recomienda redactarlo una vez el plan de empresa está terminado y hacerlo

desde cero, es decir, evitando reutilizar textos ya escritos.
3.2.2. Introducción
(47)
En el caso de que el plan des-
A continuación del resumen ejecutivo y el índice, el primer elemento criba un nuevo producto o servicio
de una empresa ya constituida, es
del plan de empresa debe ser una introducción que presente el nombre conveniente presentar un resumen
de su actividad, su evolución histó-
de la futura empresa47 y el equipo promotor, así como el resto de profe-
rica, su tamaño, etc.
sionales involucrados en la redacción del plan de empresa.
La presentación del equipo promotor debe incluir, como hemos visto, el his-
torial profesional de cada uno de sus miembros y los conocimientos que apor-
tan al proyecto empresarial. Es bastante frecuente que una parte del equipo
promotor tenga un perfil especializado en gestión empresarial, pero que tam-
bién cuente con especialistas en determinadas áreas tecnológicas, como en el
caso de las empresas que trabajan con software libre.
Por último, la introducción debe proporcionar una breve descripción de los

diferentes apartados del plan de empresa que se desarrollarán posteriormente.
Misión y visión
La introducción es un buen lugar para presentar la misión y la visión de la

nueva empresa, de manera que el lector pueda comprobar como estos dos
conceptos se desarrollan en el plan de empresa.
La misión y la visión de una organización permiten definir de una manera

concisa sus principales características y objetivos y las estrategias para llevarlos
a cabo.
La misión consiste en una frase concisa que justifica la existencia de

la organización, es decir el propósito básico hacia el que apuntan sus
actividades, y los valores que guían las actividades de sus empleados.
La misión está fuertemente vinculada a los valores internos de la orga-
nización, y describe en buena medida cómo competir y generar valor
al cliente.
La visión es también una frase concisa que describe las metas a medio
y largo plazo de la organización. La visión está orientada al mercado
y debe expresar de una manera colorista y visionaria cómo quiere la
organización ser percibida por el mundo.
Las principales diferencias entre misión y visión se resumen en lo siguiente:
• La misión describe los aspectos internos de la organización y su funciona-

miento, mientras que la visión describe los aspectos externos.
• La misión tiene su horizonte en el corto y medio plazo, poniendo especial

énfasis en los aspectos que se deben poner en práctica inmediatamente en
la organización, mientras que la visión se fija a medio y largo plazo y da
las líneas generales de la evolución de la organización en el futuro.
Corcaribe Tecnología y eZ Systems
La empresa Corcaribe Tecnología, especializada en productos y servicios basados en soft-

ware libre, se fija la siguiente misión:
"Corcaribe Tecnología provee soluciones tecnológicas que generan valor agregado bajo
un modelo de negocio que permite ofrecer a sus clientes el mejor coste por los resultados
entregados, produciendo auténticos beneficios tangibles e intangibles a sus miembros y
colaboradores."
Y la siguiente visión:
"Convertirse en referencia latinoamericana de continuo éxito en la implementación de

soluciones tecnológicas integrales aplicando preceptos y valores del conocimiento libre
dentro de un modelo de desarrollo sustentable."
Del mismo modo, eZ Systems, que ofrece software libre de gestión de contenidos se pro-
pone la siguiente misión:
"Ser la primera plataforma de gestión de contenidos en 2012."
Y la siguiente visión:
"Ayudar a las empresas a gestionar, publicar y compartir la información."
La definición de una misión y una visión no es imprescindible en un plan de

empresa, pero puede ayudar a sintetizar los objetivos a corto, medio y largo
plazo del proyecto empresarial y a transmitirlos eficazmente a los potenciales
inversores.
3.2.3. Descripción del negocio
Es recomendable comenzar este apartado con una descripción de la empresa

que se desea crear y con una breve presentación de los promotores del proyec-
to, aunque ya se haya realizado previamente en la introducción.
El objetivo esencial de este apartado es describir los productos o servicios

para los cuales se está realizando el plan de empresa o de negocio, así
como el modelo de negocio bajo el que van a ofrecerse, tal como se ha
visto en el apartado anterior.
Se debe prestar especial atención a explicar las particularidades de los modelos

de negocio basados en software libre y tener siempre en cuenta que el lector del
plan de empresa no tiene por qué estar familiarizado con ellos; por ejemplo,
en los aspectos relacionados con la protección de la propiedad intelectual y
los derechos sobre los productos o servicios.
Del mismo modo, es conveniente explicar las necesidades que los productos
o servicios van a cubrir y las principales diferencias respecto a la oferta ya
existente, a fin de mostrar que el proyecto empresarial está bien posicionado
en el mercado.
Finalmente, es necesario presentar la capacidad de producción y prestación

de servicios, lo que servirá de introducción al próximo apartado dedicado a la
organización de la producción.
3.2.4. Organización de la producción
Dentro del plan de empresa, el apartado dedicado a la organización de

la producción aporta una descripción de las tareas técnicas de la futura
empresa.
Hasta ahora se ha contemplado la posibilidad de que el plan de empresa o de

negocio describa la comercialización de un nuevo producto o servicio, indis-
tintamente. Según se trate de uno u otro, este apartado del plan de empresa
tendrá una de las siguientes formas:
• En el caso de que la actividad de la empresa esté basada en el desarrollo,

producción y posterior comercialización de un producto, se describirán en
detalle las fases de desarrollo y producción.
• En el caso de que la empresa se dedique a la prestación de un servicio sin

ningún proceso productivo, se describirán en detalle los procedimientos
para la prestación del servicio y las necesidades técnicas.
Por supuesto, estos dos casos no son excluyentes y en un plan de empresa se

pueden dar ambas. Por ejemplo, una empresa especializada en migración de
sistemas a software libre que también ofrece servicios de formación en tecno-
logías basadas en software libre a usuarios y a personal técnico.
En general, la actividad empresarial que implica las fases de investigación,

desarrollo y producción presenta una complejidad mucho mayor, y también
mayores riesgos:
• Fase�de�investigación�y�desarrollo. La descripción de la fase de investi-

gación y desarrollo debe prestar especial atención a la estimación de la
duración de la fase de investigación y desarrollo y de las necesidades de
inversión en recursos materiales y humanos.
Especialmente en sectores de alta tecnología, como es el caso del softwa-
re libre, el plan de empresa debe evaluar la capacitación de los recursos
humanos y el know-how necesarios para el éxito de las tareas de investiga-
ción y desarrollo. Por otra parte, este apartado debe describir en detalle
la distribución de funciones y responsabilidades, los riesgos inherentes a
toda actividad de investigación y desarrollo, las potenciales sinergias entre
proyectos, el proceso de innovación y mejora continua de los productos
y cómo este proceso va a integrarse en el proceso de producción. D'altra
banda, aquest apartat ha de descriure en detall la distribució de funcions i
responsabilitats, els riscos inherents a tota activitat d'investigació i desen-
volupament, les potencials sinergies entre projectes, el procés d'innovació
i millora continuada dels productes, i la manera com s'integrarà aquest
procés en el procés de producció.
(48)
• Fase�de�producción. La descripción del proceso productivo debe descri- Esto incluye la capacidad pro-
48 ductiva en número de unidades y
bir en primer lugar el ciclo operativo , la localización de las instalaciones la producción esperada, así como
de producción, su coste y su accesibilidad. En segundo lugar, es necesario el personal y el número de horas o
turnos necesarios para la produc-
describir los locales, edificios y equipos necesarios para la producción o ción.
prestación de los servicios. Para cada uno de éstos se deben presentar las
(49)
modalidades de financiación y adquisición49, sus características, su dispo- Igualmente, se puede presentar
los planes de expansión de las ins-
nibilidad, su duración y su amortización anual. talaciones y de adquisición de nue-
vos equipos.
Se debe prestar especial atención a la gestión de la calidad, con la descripción

de los estándares y certificaciones de calidad que se van a aplicar tanto a los
procesos como a los resultados del proceso productivo.
(50)
Finalmente, se debe dar una visión estratégica del proceso productivo, por Por ejemplo, un editor de soft-
ware libre podría subcontratar la
ejemplo en el caso de que se subcontrate la producción de algunos compo-
producción del soporte de distri-
nentes o una parte del proceso productivo50. bución y del embalaje de sus pro-
gramas.
De nuevo, la descripción del proceso productivo de software libre presenta una

Ampliando información
serie de diferencias respecto al desarrollo de software propietario, que deben
ser explicadas adecuadamente en el plan de empresa, aún más cuando el lector En el apartado "Producción de
software libre" de la tercera
puede no estar familiarizado con el software libre. Igualmente, es conveniente unidad se estudian en detalle
las particularidades del proce-
incidir en la calidad añadida que supone el software libre respecto al software so de producción de software
propietario. libre.
En cualquier caso hay que recordar que siempre se deben presentar las ventajas
y desventajas de las distintas alternativas y justificar cada una de las decisiones.
3.2.5. Organización interna y recursos humanos
Este apartado del plan de empresa concreta la organización del equipo

de trabajo necesario para el desarrollo del proyecto empresarial y los
perfiles necesarios.
(51)
En primer lugar, se debe incluir una descripción de las funciones y puestos Incluye su experiencia profesio-
nal, su especialización y los princi-
de dirección clave, junto a los perfiles necesarios e incluso el nombre y currí-
pales logros en su carrera. Este ti-
culo51 de las personas que vayan a ocupar estos puestos en el caso de que ya po de información cumple una do-
ble función: por un lado refuerza
estén decididas. En segundo lugar, se deben describir las diferentes categorías la confianza de los inversores po-
tenciales y, por otro lado, permite
profesionales necesarias en la empresa, sus responsabilidades, las principales descubrir las fortalezas y debilida-
tareas que llevarán a cabo y la modalidad de contratación, entre otros. Es con- des del equipo gestor.
veniente indicar la remuneración correspondiente a cada tipo de trabajadores

ya ocupen cargos directivos o no.
La organización interna de la empresa se puede representar fácilmente me-

diante un organigrama, por departamentos y áreas de actividad y con las per-
sonas específicas, si existieran, en los puestos de dirección.
Este apartado debe concluir con la descripción de la política general de la em-

presa en el área de recursos humanos y decidir si es necesaria la creación de
un departamento específico de recursos humanos o la gestión de éstos puede
realizarse de forma distribuida en cada departamento.
(52)
La necesidad y la disponibilidad de personal cualificado en una determinada Por ejemplo, en el momento
de la edición de estos materiales,
área y a un coste apropiado puede suponer en ocasiones una barrera de entrada
si bien el software libre es ya co-
importante, como puede ser el caso de especialistas en software libre52. nocido y las tecnologías y solucio-
nes basadas en él bastante popu-
lares, es difícil encontrar profesio-
nales que hayan participado acti-
Además, una empresa que base su modelo de negocio en software libre puede vamente en proyectos de software
precisar de puestos y responsabilidades adaptados a sus particularidades. Por libre, ya sea como empleados en
una empresa o por propia iniciati-
ejemplo, junto a los puestos clásicos de director técnico o director comercial, va.
se pueden encontrar roles como director de comunidad, responsable de la ges-
tión de las relaciones con los desarrolladores y usuarios de software libre o di-
rector de proyectos en cooperación, responsable de la gestión y coordinación
de proyectos que se lleven a cabo en colaboración con otras empresas, centros
de investigación o universidades.
3.2.6. Estudio de mercado
El estudio de mercado es una parte fundamental de un plan de empresa,

y por tanto una de las claves de su éxito.
Un buen estudio de mercado va a permitir evaluar correctamente la

viabilidad técnica y económica del proyecto empresarial y a identificar
los potenciales clientes y competidores, de manera que se pueda definir
la estrategia adecuada para vender los productos o servicios objeto del
plan de empresa.
En la elaboración de un plan de empresa es conveniente realizar el estudio de

mercado en primer lugar, o al menos en una primera aproximación, ya que
sus resultados pueden afectar a diferentes partes del plan de empresa.
Así, el análisis de mercado debe proporcionar información sobre los aspectos

siguientes:
• Situación�actual�del�mercado. En primer lugar, es necesario segmentar

el mercado de acuerdo a las características más relevantes en el plan de
empresa y determinar su volumen, así como su evolución histórica. Igual-
mente, hay que determinar el proceso de decisión en el mercado y el com-
portamiento de los clientes, en particular su reacción ante la introducción
de nuevos productos o servicios.
En segundo lugar, hay que evaluar las posibles necesidades que podría ge-
nerar la introducción de los productos o servicios propuestos en el plan de
empresa. Esto depende en buena medida de si el producto o servicio aporta
algo nuevo y de la capacidad de influir en los hábitos de los clientes.
• Previsiones�sobre�el�crecimiento�del�mercado. Una vez se conoce el es-

tado actual del mercado hay que ser capaz de realizar previsiones sobre
su evolución futura. ¿Se trata de un mercado en crecimiento, estable o en
decadencia? ¿Cuál es el nivel de fragmentación del mercado? ¿Se está pro-

duciendo un proceso de concentración?
De nuevo, hay que tener en cuenta la influencia que los nuevos produc-
tos o servicios podrían tener en el mercado. Por ejemplo, la introducción
de soluciones basadas en software libre puede efectivamente cambiar el
mercado, al propiciar la formación de un nuevo sector especializado en
software libre.
• Identificación�y�clasificación�de�los�clientes. Uno de los objetivos fun-

damentales de un análisis de mercado es descubrir quiénes serán los clien-
tes potenciales de los productos y servicios propuestos. La labor de clasi-
ficar los diferentes tipos de clientes de acuerdo a ciertas características co-
munes es también muy importante, ya que permite definir diferentes es-
trategias para cada uno de ellos. Por ejemplo, una empresa que ofrezca la
implantación de sistemas de software libre para empresas se presentará de
manera distinta a sus clientes según éste sea una empresa familiar o una
gran corporación. Hay que tener en cuenta también que un mismo pro-
ducto o servicio puede ofrecerse a clientes a priori diferentes. La flexibili-
dad e interoperabilidad del software libre favorece esto último.
Por otra parte, se debe evaluar la recepción del producto o servicio por
parte de cada tipo de cliente. Siguiendo con el ejemplo anterior de una
empresa especializada en la implantación de sistemas de software libre,
una gran empresa que cuente con personal técnico dedicado puede ser
más reticente a la adopción del software libre, en parte por el miedo al
cambio, mientras que una empresa familiar puede ser más receptiva.
Finalmente, en el caso de que la futura empresa cuente ya con una car-
tera de clientes, o de que existan clientes que hayan mostrado su interés
en sus productos o servicios, es conveniente recoger esto en el estudio de
mercado.
• Análisis�de�la�competencia�y�de�sus�productos. El estudio de mercado

debe dar cuenta de los competidores de la futura empresa, así como iden-
tificar tanto sus fortalezas y debilidades como las de los productos o servi-
cios que ofrecen.
Se debe proporcionar información sobre las características de sus produc-
tos y servicios, incluyendo su precio y calidad, así como su cuota de mer-
cado y su estrategia comercial. Es muy importante identificar los líderes en
el mercado de cada uno de los productos o servicios previstos en el plan
de empresa.
Igualmente, no se deben descuidar los potenciales competidores en el fu-
turo, es decir, qué empresas que todavía no están en el mercado podrían
entrar en él; ni tampoco los de otras regiones geográficas. En el contexto
actual y especialmente en los sectores relacionados con las tecnologías de
la información y las comunicaciones, como el software libre, la compe-
tencia tiende a ser global y muchas empresas pueden ofrecer sus servicios
directa o indirectamente en cualquier lugar.
• Análisis�de�las�barreras�de�entrada. Las barreras de entrada son los obs-

táculos que toda empresa se encuentra al entrar en un nuevo mercado.
Por ejemplo, la necesidad de una fuerte inversión en el caso de empresas
de nueva creación o la ausencia de una marca establecida. Por ejemplo,
el software libre se encuentra a menudo con la falta de calidad percibida,
frente a empresas y soluciones de software propietario establecidas en el
mercado.
Claro que, de la misma manera, se pueden estudiar qué barreras de entra-
da se pueden favorecer una vez instalados en el mercado, para mantener
alejada la competencia.
• Influencia�de�las�administraciones�públicas. El estudio de mercado de-

be tener en cuenta el modo en que las administraciones públicas, loca-
les, regionales, nacionales o internacionales pueden afectar al mercado y,
en consecuencia, a la viabilidad del plan de empresa. Así, las administra-
ciones pueden actuar como reguladoras del mercado, pero también como
proveedores y como clientes.
Esto es particularmente cierto en el caso del software libre, que como se
ha visto a lo largo de la asignatura es motivo de interés de múltiples ad-
ministraciones, como la Junta de Extremadura o el Gobierno de Brasil.
La realización de un estudio de mercado se debe planificar cuidadosamente
y atraviesa diferentes fases, que se resumen en las siguientes:
– Recogida de información general, donde se obtiene un gran volumen
de datos sobre el mercado objeto de estudio.
– Análisis de la información obtenida.
– Búsqueda selectiva de información, donde se obtiene la información

ausente y necesaria para completar el estudio de mercado, que se habrá
identificado tras el análisis previo.
Para llevar a cabo la elaboración de un estudio de mercado se necesita una

gran cantidad de información, que no siempre es de fácil acceso. Existen
numerosos organismos y fuentes de información, tanto generales como
especializadas en ciertas regiones o sectores: administraciones e institutos
de estadística nacionales, administraciones regionales y locales, organis-
mos privados como las cámaras de comercio o las asociaciones de empre-
sas y revistas y publicaciones especializadas.
Un buen estudio de mercado debe concluir con un análisis estratégico53
que relacione los resultados del propio estudio con la descripción del ne-
gocio y los recursos previstos y que muestre el potencial del plan de em-
presa.
(53)
A su vez, este análisis puede apoyarse en la utilización de he-
rramientas estratégicas como el análisis DAFO (http://es.wikipedia.org/wiki/
An%C3%A1lisis_DAFO) o de las 5 fuerzas de Porter (http://es.wikipedia.org/wiki/
An%C3%A1lisis_Porter_de_las_cinco_fuerzas).
3.2.7. Plan de marketing
El objetivo del plan de marketing es la definición de las estategias co-

merciales que permitan alcanzar el volumen de facturación previsto en
el análisis económico-financiero, que se verá en detalle en el apartado
siguiente.
Por tanto, el plan de marketing detalla las acciones a llevar a cabo para explo-
tar el modelo y la oportunidad de negocio descritos en el plan de empresa y
aprovechar sus ventajas competitivas.
De este modo, el plan de marketing debe recoger los siguientes aspectos:
(54)
• Estrategia�comercial�global. La estrategia global debe definir de qué ma- Por ejemplo, poniendo en pri-
mer plano la interoperabilidad y la
nera la parte comercial se integra en el proyecto empresarial. Se debe ex-
flexibilidad y la constante revisión
plicar cómo se van a identificar los clientes y cómo se contactará con ellos, y mejoras a las que está sometido
el software libre.
cuáles son las motivaciones de los clientes al interesarse o decidirse por
los productos o servicios ofrecidos y, en consecuencia, las características
de los productos o servicios que se van a destacar para generar ventas, por
ejemplo el precio, la calidad, la garantía y el soporte técnico, etc.
El caso del software libre es bastante ilustrativo, ya que el principal recla-
mo para los potenciales clientes es la reducción de costes, y no tanto la
calidad, que a menudo es superior a la del software propietario. En cam-
bio, el cliente suele identificar los precios elevados del software propietario
con una calidad superior, y el software libre, que resulta más económico,
con una calidad inferior. Por ello, a la hora de realizar un plan de empresa
basado en un modelo de negocio de software libre es esencial destacar la
calidad superior54 del software libre.
• Estrategia�de�ventas: define cuáles son los objetivos de ventas a corto y

largo plazo así como en qué sectores del mercado se van a introducir los
productos o servicios ofrecidos en una primera fase y en el futuro. En cual-
quier caso, se deben justificar adecuadamente las decisiones, apoyándose
en los resultados del estudio de mercado.
(55)
• Estrategia�de�precios: determina en primer lugar los precios con los que Igualmente, es recomendable
comparar los márgenes propios
se van a comercializar los productos y servicios ofrecidos, comparándolos,
con los de la competencia, en el
si es posible, con los de los competidores, con una estimación del margen caso de que se disponga de tal in-
formación.
bruto de beneficios y una evaluación para determinar si este margen es
suficiente para soportar toda la actividad empresarial55.
Es muy importante justificar la política de precios, sobre todo en compara-

ción con la de los competidores. En el caso de que el precio de los produc-
tos o servicios ofertados sea superior a los de la competencia, se debe expli-
car en términos de novedad y calidad, prestaciones y garantías superiores.
En el caso de que el precio sea inferior, se debe justificar cómo se mantie-
ne la rentabilidad, por ejemplo gracias a una mayor eficiencia y menores
costes de producción. De nuevo, es muy importante explicar las causas del
bajo coste del software libre y los beneficios que lleva aparejados.
Finalmente, hay que tener en cuenta que la estrategia de precios debe ser la
óptima, es decir, aquella que maximice el margen de beneficios y por tanto
la rentabilidad. En ocasiones, un precio más elevado, a pesar de reducir en
parte las ventas, puede acarrear mayores beneficios.
• Política�de�ventas: recoge la composición, forma de contratación y perfil

del equipo comercial o de ventas, incluyendo comerciales y representan-
tes, en el momento de puesta en marcha de la empresa y su evolución a
medio y largo plazo. Esto incluye la política de márgenes comerciales, las
medidas de promoción que se van a ofrecer a representantes, comerciales
y también distribuidores autorizados.
Forman también parte de la política de ventas: la estimación de las ventas
de cada comecial y representante, los incentivos, los períodos de cobro
acordados a los clientes, las promociones especiales como descuentos, an-
ticipos, rappels, etc.
• Promoción�y�publicidad: debe describir las medidas que se van a poner

en práctica para atraer la atención de clientes potenciales hacia los pro-
ductos o servicios ofrecidos. Estas medidas incluyen pasar por buzoneos
electrónicos, participación en ferias y eventos comerciales, publicidad en
sitios web, etc.
Finalmente se debe cuantificar el coste de la promoción y su retorno, en
consultas de clientes y ventas cerradas.
• Servicio�posventa�y�garantías: debe describir el servicio posventa y las

garantías que se ofrecen a los productos o servicios ofrecidos, cuando sea
aplicable. Es decir, qué tipo de servicio y garantía se ofrece, su duración
temporal, su precio en el caso de que sea optativa y sus costes para la em-
presa.
En el caso del software libre, una parte del servicio posventa está propor-
cionado indirectamente por la comunidad de desarrolladores y usuarios,
que en proyectos de éxito mejoran constantemente el producto. El plan de
empresa basado en software libre debe tener esto en cuenta y presentarlo
como una ventaja, pero nunca como el único soporte añadido. Hay que
tener en cuenta que la inmensa mayoría de los clientes desean que el ser-
vicio posventa esté incluido y garantizado en las condiciones de la venta.
Por último, se debe valorar también la importancia del servicio posventa

y de las garantías ofrecidas en la decisión final del cliente, y comparar el
servicio propio con el proporcionado por los competidores.
(56)
• Política�de�distribución: La política de distribución debe describir los ca- Por ejemplo, el programa
de asociados del ERP basado
nales de distribución que se van a utilizar y las políticas de descuentos,
en software libre Openbravo,
comisiones y márgenes asignados a cada uno de estos canales. que podéis consultar en http://
www.openbravo.com/partners/
En los modelos de negocio de software libre encontramos con frecuencia join-openbravo/details/.
56
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 promoción.
Por otra parte, como se ha comentado anteriormente, los productos y ser-
vicios de software libre pueden ofrecerse a menudo sin problemas en el
mercado global, por lo que el plan de marketing debe estudiar esta posi-
bilidad y las particularidades que presentaría, incluyendo el efecto de las
leyes internacionales en la actividad de la empresa, la gestión de los cobros
en el extranjero, etc.
3.2.8. Análisis económico-finaciero
El análisis o estudio económico-financiero es también uno de los ele-

mentos básicos de todo plan de empresa, ya que su objetivo es evaluar la
viabilidad y el potencial económico del proyecto empresarial, detectar
las necesidades de inversión para su puesta en marcha, identificar los
recursos disponibles inicialmente y presentar las distintas posibilidades
de financiación.
Contrariamente a lo que podría parecer, el análisis económico-finaciero es una

de las partes más creativas de la elaboración de un plan de empresa.
Los estados finacieros o aspectos fundamentales que debe cubrir el análisis

económico-finaciero son los siguientes:
(57)
• Estado de la tesorería durante el primer año desglosada por meses, a fin de Incluso planes de empresa con
57 un fuerte componente tecnológi-
reflejar los efectos de la estacionalidad . co, como los basados en softwa-
re libre, se ven afectados por la es-
tacionalidad de la economía, por
• Análisis del fondo de maniobra, que permite conocer la liquidez patrimo- ejemplo durante las vacaciones de
verano.
nial de la empresa.
• Cálculo del punto de equilibrio y alternativas en el caso de que el volumen

de ventas objetivo no se alcanzara.
• Necesidades y alternativas de financiación, elegiendo las más rentables y

aportando los elementos que justifiquen la decisión.
• Balances anuales a cinco años vista, con el primer año desglosado por me-
ses.
• Origen y aplicación de los fondos, que permite pronosticar situaciones de

riesgo para la empresa y evaluar la procedencia y utilización de fondos a
largo plazo.
Fondo de maniobra
El fondo de maniobra mide el equilibrio patrimonial de una entidad, ya que acredita la

existencia de activos líquidos en mayor cuantía que las deudas con vencimiento a corto
plazo. Podéis obtener más información en http://www.innovaceei.com/es/knowledgeba-
se/index.asp?faqsRecid=385&faqRecid=385&show=4460.
Es conveniente realizar un análisis conjunto de estos estados financieros y ob-

tener unas conclusiones que aporten información sobre el proyecto empresa-
rial en su conjunto: la cantidad de capital necesario y cuándo será necesario,
y la deuda necesaria y cuándo se debe pagar esta deuda, entre otros.
Igualmente se debe explicar la rentabilidad esperada de la inversión y cuándo

se recuperará esa inversión.
Como se comentó anteriormente, hay que evitar caer en la tentación de pre-

sentar un análisis económico-finaciero demasiado optimista para ganarse la
confianza de los inversores, ya que tarde o temprano se volverá contra la pro-
pia empresa y pondrá en entredicho su viabilidad y credibilidad.
3.2.9. Forma legal
(58)
Si el objetivo último del plan de empresa es efectivamente la creación de una En el caso de que se tratara de
58 un plan de negocio para una em-
nueva empresa , se debe elegir la forma legal con la que ésta se va a constituir, presa ya constituida, este apartado
su régimen fiscal y sus socios fundadores. Del mismo modo, se debe recoger describiría la naturaleza jurídica de
ésta y las posibles modificaciones
el nombre de todos los socios e inversores y su participación en la nueva so- que la implementación del plan de
negocio podría llevar consigo.
ciedad.
Es conveniente detallar paso a paso todos los trámites necesarios para cons-
tituir la nueva empresa, así como su coste y el tiempo necesario para su eje-
cución. Se debe también especificar si se va a recurrir a servicios de asesoría
externa especializada y su coste.
3.2.10. Gestión de riesgos
Todo proyecto empresarial, ya se trate de la creación de una nueva empresa Ampliando información
o de una nueva línea de negocio, implica numerosos riesgos que en ocasio-
En el apartado "Gestión de
nes son ineludibles. Por ello, el plan de empresa debe incluir una descripción riesgos" de la primera unidad
completa de los riesgos y de sus consecuencias. podréis encontrar una intro-
ducción general a este tema.
Los riesgos pueden clasificarse según sean internos, con origen en la propia
empresa, o externos, y según al área funcional que afecten: técnica, comercial,
etc.
Por ejemplo, riesgos internos pueden ser la existencia de retrasos en la produc-

ción o falta de personal cualificado, mientras que riesgos externos puede ser
una nueva regulación del mercado, que reduzca en parte la rentabilidad o la
aparición de nuevas tecnologias que dejen obsoletos los productos o servicios
ofrecidos.
(59)
Para cada riesgo se debe definir un plan de contingencia, lo que incluye una Por ejemplo, para prevenir la
59 aparición de nuevas tecnologías
serie de acciones de prevención , es decir, para evitar que el riesgo llegue a que pudieran dejar obsoletos los
productos o servicios previstos en
realizarse, y una serie de acciones de mitigación o remedio60, qa adoptar en el el plan de empresa se debería po-
caso de que el riesgo se realice. ner en práctica una vigilancia tec-
nológica activa y, eventualmente,
colaborar con empresas u organi-
Hay que tener en cuenta que algunos riesgos pueden provocar efectos negati- zaciones que trabajen en la misma
área.
vos, pero también positivos. Por ejemplo, cambios en el marco legal o político
que pueden afectar al modelo de negocio, pero al mismo tiempo dar lugar a (60)
Por ejemplo, se podrían asig-
nuevas oportunidades de negocio. nar recursos humanos y materiales
provenientes de otros departamen-
tos a fin de recuperar el retraso en
La correcta identificación y evaluación de los riesgos en un proyecto empresa- la producción.
rial y la preparación de planes de contingencia adecuados, antes que denotar

debilidades del proyecto, destacan las habilidades de gestión y de previsión de
los promotores y aumentan su credibilidad.
3.2.11. Resumen y evaluación
El último apartado del plan de empresa debe resumir los puntos fuertes
y débiles del proyecto empresarial, las ventajas y oportunidades que
ofrece y las principales amenazas y riesgos.
El resumen es la última oportunidad para convencer a un inversor potencial,

así que se debe ser muy convincente y aprovecharlo para reforzar los argumen-
tos a favor del proyecto empresarial y en los que creen sus promotores.
Sin embargo, puede darse la posibilidad de que tras la elaboración del plan de
empresa los propios promotores del proyecto descubran que éste no sea tan
rentable como se esperaba, o incluso completamente inviable. Esto muestra la
utilidad del plan de empresa como herramienta para la identificación de las
mejores oportunidades de negocio.
3.2.12. Plan de empresa y software libre
La elaboración de un plan de empresa basado en software libre no presenta

grandes diferencias respecto a los planes de empresa de otros sectores y algu-
nas de sus particularidades ya se han presentado a lo largo de los apartado
anteriores.
En general, hay que recordar que un plan de empresa puede estar dirigido a
diferentes tipos de lectores: asesores, inversores, técnicos, banqueros. Por ello
se debe emplear un lenguaje comprensible por todos ellos y evitar la utilización
de un vocabulario demasiado técnico. Cuando la utilización de estos términos
sea inevitable, es recomendable explicar bien cada uno de los conceptos en
un lenguaje accesible. Un inversor nunca invertirá en algo que no comprende
del todo.
Igualmente, hay que prestar atención a explicar las particularidades del soft-
ware libre, haciendo hincapié en las diferencias respecto al software propieta-
rio y sus principales ventajas. No hay que dudar en recurrir a ejemplos reales
y casos de éxito que refuercen los argumentos presentados en el plan de em-
presa.
Por otra parte, si bien el software libre comienza a tener un papel cada vez
más relevante en los medios y en la sociedad gracias al compromiso de la
comunidad de software libre, de empresas y de administraciones públicas, su
naturaleza y sus implicaciones económicas no son tan conocidas.
De nuevo, hay que prestar mucho cuidado a explicar correctamente los mo-
delos de negocio basados en software libre y estar preparado para responder e
incluso anticipar las preguntas más frecuentes. Por ejemplo, ¿cómo se puede
invertir y ganar dinero en algo que cualquiera puede copiar?
3.3. Producción de software libre
Buena parte de los modelos de negocio presentados en el primer apartado

dependen, en mayor o menor medida, del desarrollo de software libre.
Uno de los problemas a la hora de hablar de proyectos de software libre es que

tan solo los proyectos exitosos tienen repercusión en la comunidad y sólo los
muy exitosos llegan a los medios no especializados.
Sin embargo, antes de abordar la producción de software libre hay que recordar
que la inmensa mayoría de proyectos de software libre son un fracaso, por
unas razones o por otras. Puede deberse simplemente a que el proyecto no
consigue producir un software de calidad y competitivo, o bien porque no
consigue atraer la atención de la comunidad de desarrolladores y usuarios.
Por supuesto, y como se ha visto en los materiales de la asignatura, no hay

que olvidar que un proyecto de software libre debe tratarse como un proyecto
de software, y en último lugar, simplemente como un proyecto de ingeniería.
Por ello, todo proyecto de software libre presenta en primer lugar los mismos
riesgos y problemas que cualquier otro proyecto.
Sin embargo, y dada la naturaleza libre de este tipo de proyectos, hay también
otras fortalezas y debilidades que conviene conocer. Por el carácter aparen-
temente no profesional de muchos proyectos de desarrollo de software libre
puede parecer que la ejecución de éstos, respecto a la de los proyectos de desa-
rrollo de software tradicionales, sea más sencilla. Nada más lejos de la realidad.
El objetivo de este apartado es presentar las particularidades de los proyectos

de desarrollo de software libre respecto al desarrollo de software propietario y
mostrar una serie de buenas prácticas que faciliten su éxito. Estas prácticas se
corresponden con las principales áreas y elementos necesarios para poner en
marcha y ejecutar un proyecto de software libre, que son las siguientes:
• Creación y presentación del proyecto
• Infraestructura necesaria
• Organización de la comunidad
• Desarrollo
• Releasing y packaging
• Elección de licencias
Por supuesto, no todos estos pasos son obligatorios. Como se ha visto en los
modelos de negocio, una empresa dedicada al software libre puede ser la ini-
ciadora del proyecto, o bien, en la mayoría de los casos, unirse a un proyecto
ya existente.
Esta última opción es con frecuencia la más recomendable y, de hecho, dada

la naturaleza del software libre, no excluye la posibilidad de que a partir de
un proyecto existente se cree uno nuevo con la identidad de la empresa o la
organización interesada en dirigir su desarrollo.
3.3.1. Creación y presentación del proyecto
Este apartado se ocupa fundamentalmente de los pasos necesarios para crear

un nuevo proyecto de software libre y presentarlo a la comunidad.
Así, el primer paso antes de crear un nuevo proyecto es descubrir si existe al-
gún proyecto que realice al menos en parte lo que se pretende. Si hay un pro-
yecto similar de software libre al que se puede contribuir, o que se puede rea-
provechar para poner en marcha el nuevo proyecto, es conveniente ponerse
en contacto con sus responsables para explorar las posibilidades de colabora-
ción y sus planes futuros.
Buscadores genéricos
Los buscadores genéricos son la primera etapa para descubrir proyectos existentes, así
como los sitios de noticias, los directorios y las forjas públicas como http://freshmeat.net,
http://directory.fsf.org y http://www.sourceforge.net.
Si se ha decidido crear un nuevo proyecto, lo primero que hay que hacer es

elegir un nombre que lo identifique en la comunidad. Como regla general,
un buen nombre debe dar una idea de qué hace el software, o al menos de su
campo de aplicación, y debe ser fácil de recordar.
(61)
Para bien o para mal, el inglés es la lengua oficial de facto en Internet. Por ello, Es decir, que sea un nombre co-
mún a varias lenguas, como Apa-
si el proyecto busca tener un impacto global, y así debería ser en la mayoría
che, o que no se asocie a otra len-
de los casos, es conveniente que el nombre tenga cierto significado en inglés, gua mayoritaria, como por ejem-
plo Ubuntu.
o bien que sea neutro61.
(62)
Es decir, los dominios .com,
Por otra parte, se debe prestar atención a los aspectos legales, de manera que .net y .org.
el nombre no entre en conflicto con marcas registradas y que los potenciales

dominios de alto nivel62 en Internet asociados estén disponibles.
De la misma manera que se ha visto en el apartado dedicado a la creación de

un plan de empresa, todo proyecto debería contar con una definición clara de
su misión, que atraiga la atención de usuarios y desarrolladores y les permita
decidir si están interesados en el proyecto, o no.
Junto a la misión, es igualmente importante identificar inequívocamente el

proyecto como software libre, lo cual implica hacer una referencia clara a soft-
ware libre (free software) o software de código abierto (open-source software).
Otros elementos importantes a la hora de presentar un proyecto de software

libre son:
(63)
• Lista�de�funcionalidades�previstas63�y�requisitos�actuales. Redactada de Se pueden indicar con una
mención "en progreso" o "en desa-
una manera sencilla, es decir, sin tecnicismos. Es, en cierto modo, un resu- rrollo", idealmente con la fecha o
men detallado de lo que hace el software, que permita a los usuarios saber la versión en que estarán disponi-
bles.
fácilmente si se trata de las funcionalidades que buscan.
De igual modo, los requisitos deben ser fáciles de entender, de manera que
el usuario sepa si puede instalar y utilizar la aplicación en su sistema.
• Estado�de�desarrollo. En la comunidad de software libre los usuarios sue-

len estar muy interesados en saber cómo avanza el desarrollo del proyec-
to, tanto si se trata de un nuevo proyecto como de uno ya maduro. Para
ello deben explicarse los objetivos del proyecto a corto y largo plazo, las
funcionalidades en las que se está trabajando actualmente y que estarán
disponibles en futuras releases, etc.
(64)
• Descargas�disponibles. El código fuente debe poder descargarse siempre Es conveniente, por ejemplo,
evitar procesos de registro de
en formatos estándar, de una manera sencilla, que no suponga ninguna
usuarios para acceder a la sección
complicación para el usuario64. de descargas.
El proceso de instalación también debe ser sencillo y, sobre todo, de acuer-

do a los estándares desde el principio del proyecto. Igualmente, en un pri-
mer momento no es necesario facilitar paquetes binarios o ejecutables, a
menos que el proceso de compilación sea muy complejo.
• Repositorio� de� desarrollo. Los potenciales desarrolladores, al contrario

que los usuarios, están más interesados en acceder al repositorio de trabajo,
donde se puede seguir la evolución del proyecto día a día y participar en
ella, ya sea añadiendo nuevas funcionalidades o corrigiendo errores. Para
ello es conveniente que todos puedan acceder a la lectura del repositorio,
mediante un acceso anónimo.
(65)
• Seguimiento�de�errores. Al igual que el repositorio, la base de datos de Con frecuencia se hace referen-
65 cia a los términos bug tracker o bug
seguimiento de errores debe estar también abierta a todos. Paradójica- database en inglés.
mente, un proyecto es mejor cuantos más errores contiene su base datos,
ya que esto implica un mayor número usuarios y una mayor participación
de los usuarios en el proyecto.
Al inicio del proyecto, el número de errores será muy bajo. Una buena
práctica es registrar en la base de datos los errores resueltos internamente
por el equipo que pone en marcha el proyecto.
• Canales�de�comunicación. Uno de los objetivos de todo proyecto de soft-

ware libre es crear una comunidad alrededor de él y, para que dicha co-
munidad se organice, es necesario facilitar los canales de comunicación
adecuados. Esto incluye listas de correo, canales de IRC, foros, etc.
En una primera fase del proyecto es conveniente no diversificar ni espe-
cializar en exceso los canales de comunicación. Un único foro o lista de
distribución para usuarios y desarrolladores puede ser suficiente y favore-
cer las interacciones entre ellos.
• Documentación�para�usuarios�y�desarrolladores. La documentación es
esencial en todo proyecto de software libre, tanto para los usuarios como
para los desarrolladores.
Una buena documentación para el usuario debe explicar a éste cómo ins-
talar el software y cómo utilizar sus funciones. Se le puede facilitar tam-
bién un pequeño tutorial, que le enseñe a realizar las tareas más frecuentes
paso a paso. Un excelente complemento de la documentación es el man-
tenimiento de una sección de preguntas frecuentes o FAQ.
La documentación para desarrolladores debe incluir la información de
contacto de los principales desarrolladores del proyecto, las instrucciones
para enviar informes de errores y parches, así como una presentación so-
bre la organización del desarrollo y la toma de decisiones entre los desa-
rrolladores.
Todos estos elementos se verán en detalle en los apartados siguientes.
Para concluir este apartado cabe destacar que la apariencia –es decir, cómo
la comunidad de software libre percibe el proyecto– tiene un papel bastante
importante en el éxito o el fracaso de un proyecto de software libre.
Muchos desarrolladores no prestan suficiente atención a esta tarea de comu-

nicación y relaciones públicas, la cual, sin embargo, es un elemento indispen-
sable en prácticamente todos los proyectos de software libre de éxito.
Para ello hay que definir claramente cuales son los objetivos del nuevo soft-
ware, que normalmente se pueden resumir en:
• Definir�claramente�qué�hace�el�software: sus funcionalidades principa-

les, el estado actual de desarrollo y los planes de futuro, además de su po-
sicionamiento respecto a las soluciones y los proyectos ya existentes.
• Dar�a�conocer�el�software: hacerlo llegar a la comunidad o al mercado de

usuarios y desarrolladores potencialmente interesados.
• Potenciar�el�uso�del�software: que los usuarios y los desarrolladores po-

tenciales sepan utilizar el nuevo software y lo adopten frente a las solucio-
nes alternativas.
• Involucrar�nuevos�desarrolladores�en�el�proyecto: que éstos contribu-

yan al desarrollo del proyecto mediante la implementación de nuevas fun-
cionalidades y que aporten sus puntos de vista sobre la dirección que de-
bería tomar el proyecto en el futuro.
Los dos últimos objetivos, conseguir muchos usuarios y muchos desarrollado-

res, son a menudo los más importantes. Sin embargo, es necesario poner en
práctica una estrategia para los usuarios y otra diferente para los desarrollado-
res, los cuales, aun perteneciendo a la misma comunidad de software libre,
representan audiencias muy distintas.
Se debe definir claramente el mensaje que quiere hacerse llegar a cada uno de
ellos y estructurarlo con una complejidad progresiva, de modo que el nivel de
detalle ofrecido se corresponda con el esfuerzo requerido por parte del lector.
Por ejemplo, no tiene sentido saturar al usuario con la arquitectura del soft-
ware, ni tampoco adentrar a los desarrolladores en detalles técnicos sin antes
dar una visión adecuada de la arquitectura.
Finalmente, este mensaje debe ser fácilmente accesible y puede hacerse llegar
a sus destinatarios mediante anuncios en foros o comunidades relacionadas,
en el sitio web del proyecto e incluso en la documentación, entre otros.
3.3.2. Infraestructura
Cualquier proyecto de software libre necesita una serie de herramientas

que permitan gestionar la información que se genera en el día a día del
proyecto, desde el código desarrollado hasta las comunicaciones entre
sus miembros.
Algunas de estas herramientas ya se han introducido en el apartado anterior,

pues son esenciales para poner en marcha el proyecto:
• Sitio�web
Proporciona una fuente centralizada de información sobre el proyecto y
da acceso a otras herramientas de gestión especializadas.
• Listas�de�correo
Es uno de los canales de comunicación utilizados con más frecuencia en
los proyectos de software libre. Los intercambios de mensajes suelen que-
dar archivados y se utilizan como referencia y base de conocimiento del
proyecto.
• Sistema�de�control�de�versiones
Permite que los desarrolladores controlen la creación y la gestión de códi-
go, volviendo a versiones anteriores y uniendo diferentes versiones. Gra-
cias al sistema de control de versiones, cualquiera puede visualizar el esta-
do actual del código, así como su evolución en el tiempo.
• Sistema�de�seguimiento�de�errores
Permite que los desarrolladores realicen un seguimiento de las funcionali-
dades y los errores en los que está trabajando cada uno, se coordinen entre
ellos y planifiquen las próximas releases. Si bien el seguimiento de errores
es su función principal, la base de datos puede utilizarse igualmente para
realizar el seguimiento de cualquier tarea del proyecto, como las nuevas
funcionalidades.
Gracias al sistema de seguimiento de errores, cualquiera puede saber si un

determinado error ha sido solucionado o si alguien está trabajando en él.
Junto al sistema de control de versiones, permite conocer el dinamismo y
la actividad registrada del proyecto.
• Chat�o�canal�de�conversación
Proporciona un canal de comunicación donde resolver dudas y problemas
rápidamente. Las conversaciones no se suelen archivar, por lo que es acon-
sejable que las discusiones más complejas tengan lugar en listas de correo.
Cada una de estas herramientas responde a unas necesidades concretas, prin-

cipalmente de comunicación y de gestión de la información. La experiencia y
las características de la comunidad de usuarios y desarrolladores alrededor del
proyecto van a dictar la configuración y el uso de estas herramientas. No obs-
tante, vale la pena comentar algunos aspectos que pueden resultar de utilidad
para la mayoría de proyectos de software libre.
Las listas de correo son un elemento esencial de todo proyecto de software Recursos web
libre, por lo que hay prestar especial atención a su gestión y uso. Es práctica-
Entre los sistemas más
mente obligatorio disponer de un sistema gestor de listas de distribución, cuya populares están Mail-
configuración y mantenimiento pueden resultar complicados en un principio. man (http://www.list.org),
Smartlist (http://
www.procmail.org), Ecar-
Las funcionalidades y las opciones principales de un sistema gestor de listas tis (http://www.ecartisorg),
Listproc (http://
de distribución son las siguientes: listproc.sourceforge.net)
o Ezmlm (http://cr.yp.to/
exmlm.html).
• Suscripción mediante correo electrónico y mediante una interfaz web
(66)
En el modo digest se recibe una
• Suscripción en modo digest o normal66 compilación de todos los mensajes
periódicamente, normalmente ca-
da mes o cada semana, mientras
• Moderación que en el modo normal los mensa-
jes se reciben inmediatamente.
• Interfaz de administración
• Configuración de las cabeceras de los mensajes
• Gestión y consulta de archivos
Por otra parte, las listas de correo se pueden integrar con otras herramientas
tales como el sistema de control de versiones o el sistema de seguimiento de
errores para notificar, por ejemplo, cambios en el código fuente o modifica-
ciones en el estado de errores y tareas en curso.
Igualmente, el sistema de control de versiones es un elemento indispensable

para cualquier proyecto de software libre que aspire a articular una comunidad
de desarrolladores. El funcionamiento de casi todos los sistemas de control de
versiones se basa en la existencia de una copia remota, compartida por todos
los desarrolladores y de la que se pueden consultar todas las versiones. Cada
desarrollador dispone de una copia local de esa copia remota, sobre la que
trabaja. Puntualmente, cada desarrollador envía sus modificaciones a la copia
remota, compartiéndolas con el resto.
Las funcionalidades principales de un sistema de control de versiones son:
• Commit: integrar los cambios de la copia local en la copia remota, los

cuales quedan así registrados en la base de datos de control de versiones.
• Update: integrar los cambios de los demás desarrolladores en la copia local.
• Checkout: obtener una copia local a partir de la copia remota.
Vale la pena destacar que, dentro del proyecto, todo documento o archivo
editado puede y debe ser objeto de un control de versiones, por lo que éste no
se debería limitar a los archivos de código fuente. La utilización de un sistema
de control de versiones puede resultar muy práctica para editar y compartir
documentación o informes técnicos y, en general, para cualquier documento
que haya sido creado y mantenido en colaboración.
Como se ha comentado anteriormente, el sistema de seguimiento de errores

permite realizar muchas otras funciones, además de la que indica su nombre.
Esto incluye el seguimiento de cualquier tipo de tarea, como la implementa-
ción de funcionalidades nuevas, la preparación de releases o el soporte a los
usuarios.
El ciclo de vida de un error suele ser el siguiente:
• Notificación�del�error: Todo error incluye al menos un resumen y una

descripción inicial que contienen, a ser posible, los elementos necesarios
para reproducir el error. La mayoría de sistemas de seguimiento de errores
permite configurar campos específicos. No hay que olvidar que los errores
pueden venir tanto de la comunidad de usuarios como de la de desarro-
lladores.
Una vez archivado, el error queda en estado abierto y no está asignado a
nadie. Durante ese tiempo, la gente que acceda a la base de datos puede
leer la descripción del error y, eventualmente, pedir más información al
usuario o al desarrollador que lo ha notificado.
• Reproducción�del�error: Siguiendo las indicaciones de la descripción del

error, alguien consigue reproducirlo, por lo que éste queda validado. Es
decir, se puede decir que el error es auténtico.
• Diagnóstico�del�error: Durante las fases anteriores puede ocurrir que un

desarrollador se haga responsable de la resolución del error, o bien que
alguien con autoridad dentro del proyecto lo asigne al desarrollador más

adecuado.
• Asignación�del�error: durant les fases anteriors pot passar que un desen-

volupador es faci responsable de la resolució de l'error, o bé que algú amb
autoritat dins del projecte l'assigni al desenvolupador més adequat.
Es esencial notificar esto en la base de datos, a fin de evitar que dos desa-
rrolladores estén trabajando en la resolución del mismo error sin saberlo.
Es posible notificar igualmente la fecha esperada de resolución, o la release
en la que el error se habrá solucionado.
• Resolución�del�error: Una vez el desarrollador resuelve el error, lo marca

como cerrado o resuelto.
A veces los errores se resuelven rápidamente, por lo que algunas de estas fases
se pueden obviar. O incluso puede darse que el error no sea tal y que se deba
a un mal uso por parte del usuario. En cualquier caso, por sencilla que sea la
solución, siempre es conveniente registrar el error y comunicárselo adecuada-
mente al usuario.
Otra situación frecuente se da cuando varios usuarios notifican el mismo error,

lo que se conoce como errores duplicados. En este caso es conveniente agrupar
todas las notificaciones bajo una única notificación, lo que permiten concen-
trar esfuerzos y disponer de toda la información en el mismo lugar.
Finalmente, puede ocurrir que un error considerado como resuelto no lo esté

en realidad, generalmente porque el patrón de reproducción seguido no coin-
cide con el proporcionado por el usuario que ha notificado el error. En este
caso, el usuario puede reabrir el error, aportando siempre toda la información
necesaria. Existen numerosas forjas públicas que ofrecen estas y otras herra-
mientas, listas para ser utilizadas en los proyectos de software libre. Estas pla-
taformas ofrecen una serie de ventajas y desventajas.
Recursos web
Entre las forjas públicas más populares están SourceForge (http://www.sourceforge.net),

Savannah (http://savannag.gnu.org o BerliOS.de (http://www.berlios.de). Además, algu-
nas organizaciones ofrecen alojamiento a proyectos dentro de su área de interés, como
Apache (http://www.apache.org) o Tigris (http://www.tigris.org).
Entre sus ventajas cabe destacar su capacidad y el ancho de banda disponible:

no importa el posible éxito del proyecto, los servidores siempre van a estar en
funcionamiento. Vale la pena recordar el trabajo adicional que supone man-
tener un servidor de alta disponibilidad en marcha. Por otra parte, las herra-
mientas proporcionadas por estas forjas están ya configuradas y normalmente
son muy sencillas de utilizar. Evidentemente, la desventaja principal es que la
flexibilidad y las posibilidades de configuración de las herramientas ofrecidas
son limitadas.
Así, al comenzar el proyecto puede ser recomendable albergarlo en una forja

pública, pero a la vez dejar abierta la posibilidad de disponer de un alojamiento
propio en el futuro, empezando por registrar el nombre del dominio asociado
al proyecto. Por ejemplo, el hecho de disponer de un sitio web informativo del
proyecto, que redirija a una forja pública para los aspectos ligados al desarrollo
del código puede ser, aunque no una solución óptima, sí un buen compromiso.
3.3.3. Organización de la comunidad
Una de las mayores diferencias entre los proyectos de software libre y los pro-
yectos de software propietario es el modo de organizarse de la comunidad de
desarrolladores.
En un proyecto de software propietario, la organización corresponde

normalmente a la organización jerárquica del equipo o el departamen-
to que, dentro de una empresa, lleva a cabo a cabo el desarrollo. Aun-
que en un proyecto de software libre también se aprecia a veces cierta
jerarquía, parcialmente basada en los méritos de cada desarrollador, la
organización de la comunidad de desarrolladores es más flexible pero
también más fuerte.
(67)
Paradójicamente, uno de los motivos que hacen que la comunidad de desa- En inglés, forkability, es decir la
posibilidad de realizar un fork.
rrolladores 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 escisión hace que
la comunidad busque un consenso más o menos democrático en las grandes
decisiones del proyecto.
En general, existen dos formas de organización de las comunidades de softwa-

re libre, si bien la mayoría de los proyectos acaban adoptando una posición
intermedia entre ambas. Estas dos formas son las siguientes:
• Organización�basada�en�un�"dictador�benevolente".
El dictador benevolente es una figura con autoridad para tomar decisiones
definitivas, de importancia para la vida del proyecto. Sin embargo, a me-
nudo el dictador benevolente no toma las decisiones directamente, sino
que suele actuar más bien de árbitro en las discusiones, tratando de com-
patibilizar los puntos de vista de los desarrolladores e identificar las apor-
taciones más valiosas. Otra forma de actuación del dictador benevolente es
delegar en expertos que puedan ocuparse de las decisiones o discusiones en
marcha. El dictador benevolente suele ser un desarrollador con suficiente

experiencia en el proyecto y en las tecnologías relacionadas, pero que no
es necesario que sea el más experto. Basta con que sea capaz de entender el
proyecto en su totalidad y reconocer las contribuciones de mayor calidad.
• Organización�basada�en�el�consenso.
Por consenso se entiende los acuerdos que toda la comunidad acepta más
o menos tácitamente, es decir, cuando nadie se opone a las decisiones ni
a la dirección que se van tomando en el proyecto, por lo que el proceso
de consenso no suele ser en absoluto formal. No obstante, esto no impide
que cuando no se alcanza un consenso en un determinado tema, se pueda
realizar una votación.
La mayoría de discusiones en la vida de un proyecto suele ser de natura-
leza técnica, por lo que el consenso se produce cuando todo el mundo
esta de acuerdo en, por ejemplo, el diseño o la implementación de una
funcionalidad o en la manera de resolver un error. En estos casos, además,
un miembro suele hacer un resumen de la discusión al final de ésta.
En general todas las comunidades, y especialmente las basadas en el consen-

so, tienen un excelente apoyo en el sistema de control de versiones, el cual
permite volver atrás y deshacer cualquier decisión que se revele equivocada.
Los proyectos suelen comenzar con una organización basada en un dictador

benevolente y, a medida que la comunidad crece, se mueven hacia una orga-
nización más basada en el consenso. Esto suele ocurrir en ciertos momentos
de la vida del proyecto, como por ejemplo cuando el dictador benevolente
abandona su posición y su autoridad se diluye en la comunidad, especialmen-
te entre los miembros más respetados de ésta.
Al cabo de un tiempo, las convenciones y los acuerdos tomados por una co- Recursos web
munidad mediante consenso pueden ser muy grandes, por lo que es conve-
Podéis consultar las guías del
niente recoger los elementos principales en un documento que sirva de guía proyecto Subversion (http:/
y referencia en el futuro. Éste puede incluir tanto la forma de gobierno de la /svn.collab.net/repos/svn/
trunk/HACKING) o de la
comunidad, como las convenciones y las recomendaciones para los desarro- Fundación Apache (http://
lladores. www.apache.org/foundation/
how-it-works.html y http://
www.apache.org/foundation/
voting.html).
Finalmente cabe preguntarse cuál es el papel de las empresas en las comuni-
dades de software libre.
Por una parte podemos considerar el caso de una empresa que desee iniciar un
proyecto de software libre y crear una comunidad de usuarios y desarrollado-
res. Por otra parte, puede darse el caso de una empresa que se una a un proyec-
to de software libre ya en marcha. En cualquiera de los dos casos, la empresa
debe definir claramente sus objetivos respecto al proyecto de software libre y
cuál va a ser su participación en la comunidad.
Las posibilidades son muy variadas. Por ejemplo, la empresa puede buscar una
posición de liderazgo en la comunidad y dirigir el proyecto o, sencillamente,
tener voz en las discusiones, participar activamente en la implementación de
nuevas funcionalidades o dedicar solamente algunos de sus desarrolladores a
resolver los problemas de sus clientes.
Sin olvidar la gran dificultad que supone construir un proyecto exitoso de

software libre, resulta evidente que, al menos para los proyectos iniciados por
una empresa, la comunidad ya existe: es la formada por los desarrolladores de
la empresa y sus clientes.
En esta situación, el modelo de organización basado en el dictador benevo-

lente parece el más adecuado, al menos al principio, pero es necesario definir
las reglas de participación de la comunidad. El reto es, por una parte, conse-
guir que estos clientes se conviertan en usuarios activos y que participen en
la mejora del proyecto y, por otra parte, conseguir que otros desarrolladores
se involucren.
La solución, si bien difícil, pasa por ofrecer ventajas o algún tipo de valor
añadido a los usuarios y a los desarrolladores que participen en la comunidad.
Una buena práctica consiste en que el equipo de desarrollo de la empresa tra-

baje complemente integrado en la comunidad y siguiendo la metodología de
desarrollo del proyecto de software libre. Esto implica que la participación de
los desarrolladores en el proyecto debe ser duradera, a fin de familiarizarse con
el funcionamiento de la comunidad y ganar credibilidad dentro de ella.
3.3.4. Desarrollo
En este apartado se presenta el proceso de desarrollo de un proyecto de soft-

ware libre, no desde el punto de vista técnico, que dependerá de la naturaleza
de cada proyecto, sino desde el punto de vista de la gestión del proyecto y la
coordinación de los desarrolladores.
En lo que respecta al desarrollo, hay que tener en cuenta que una de las
diferencias de los proyectos de software libre respecto a los proyectos
de software propietario es la ausencia de una organización centralizada.
Por ejemplo, cuando se aproxima la fecha de una nueva release, una
empresa puede dedicar un número arbitrario de recursos a su prepara-
ción. En cambio, los desarrolladores voluntarios que forman la comuni-
dad no son tan fáciles de dirigir. Las motivaciones de cada uno de ellos
son diferentes y, si bien algunos pueden estar interesados en publicar
una nueva release a tiempo, otros pueden estar interesados solamente
en alguna funcionalidad concreta.
De este modo, la distribución de tareas en un proyecto de software libre se

basa fundamentalmente en la independencia entre éstas y la regla general es
que cada desarrollador trabaja en lo que desea y cuando lo desea.
No obstante, esta aproximación no deja de ser en parte ideal y, en la mayoría

de proyectos de software libre, resulta necesario el trabajo de una persona o
equipo que coordine a todos los desarrolladores voluntarios. Por ejemplo, este
equipo puede estar formado explícitamente por los iniciadores del proyecto
o el dictador benevolente o, implícitamente, por los miembros con más expe-
riencia y ascendencia sobre la comunidad.
Algunas de las tareas principales de coordinación, necesarias para la buena

marcha del proyecto, son:
• Delegar: una de las tareas principales de los coordinadores del proyecto

es delegar tareas en otros desarrolladores. Cuando alguien delega una ta-
rea en otra persona, y ésta acepta, el beneficio es doble: el coordinador
encuentra alguien que hace el trabajo por él y la otra persona, en cambio,
ve reconocido su trabajo, en tanto que éste le ha sido confiado. Por ello,
la mejor manera de delegar una tarea es a través de un canal de comuni-
cación visible para toda la comunidad y dando siempre la opción de de-
clinar la oferta.
En este caso, el coordinador debe conocer las habilidades y los intereses de
los miembros de la comunidad y, en función de ello, dirigir sus demandas.
Por ejemplo, no tiene sentido pedir algo a alguien que no tiene la capa-
cidad necesaria para llevarlo a cabo, ni tampoco a alguien que ya realiza
numerosas tareas.
• Realizar�críticas�y�elogios: la valoración adecuada de las contribuciones

de cada uno de los desarrolladores del proyecto tiene un papel muy impor-
tante en la creación de un ambiente cordial dentro de la comunidad y, por
supuesto, las valoraciones emitidas por los coordinadores o los miembros
con mayor ascendencia tienen una mayor repercusión en la comunidad.
Por ello, tanto las críticas como los elogios deben utilizarse cuidadosamen-
te. Hay que recordar que las críticas continuas o injustificadas van a cau-
sar seguramente una mala reacción, al igual que los elogios. Sin embargo,
en una discusión técnica, una crítica detallada puede considerarse en sí
misma como algo positivo, ya que implica que la persona que la realiza
se ha tomado el interés de analizar el diseño o la implementación objeto
de la crítica.
• Evitar�la�territorialidad: una situación a evitar es aquella en la que ciertos

miembros de la comunidad pretenden apropiarse de una parte ("su par-
te") del proyecto y no aceptan ninguna crítica o contribución de los otros
miembros. Aunque al principio dicha actitud puede parecer positiva, ya
que tales miembros suelen ser expertos y dedican mucho tiempo a su parte
del proyecto, la consecuencia a largo plazo es que ningún otro desarrolla-
dor revisa el código realizado, con la consiguiente pérdida de calidad y la

fragmentación de la comunidad.
(68)
• Automatizar�tareas: en general, la mayoría de desarrolladores trabaja en En particular, la creación de un
paquete de pruebas, un programa
una parte del código y desconoce qué es lo que hacen los demás. Por tanto,
que ejecuta el software del pro-
es responsabilidad de los coordinadores tener una visión global del proyecto a fin de reproducir todos los
errores conocidos y corregidos an-
yecto y saber a qué se dedica cada miembro. Así resulta fácil identificar teriormente. Esto permite que los
una serie de tareas inherentes al desarrollo del código que todos los desa- desarrolladores se aseguren que
no provocan de nuevo errores anti-
rrolladores llevan a cabo y que a menudo puede ser conveniente automa- guos ya resueltos.
tizar y centralizar.
El ejemplo más evidente de esto es la automatización de tests68, que per-
mite que los desarrolladores realicen cambios y experimenten con partes
del código con las que no están familiarizados.
• Tratar�adecuadamente�a�los�usuarios: la existencia de una comunidad

de usuarios activa y que proporcione información valiosa a los desarrolla-
dores es esencial para el éxito de todo proyecto de software libre. Sin em-
bargo, a menudo los desarrolladores y los usuarios hablan, por así decir-
lo, lenguajes diferentes. Muchos usuarios no están familiarizados con el
desarrollo de software ni con el funcionamiento de las comunidades de
software libre. Los desarrolladores deben ser capaces de ponerse en el lugar
de los usuarios y tratar de explicarse lo mejor posible.
Hay que pensar que todo usuario puede contribuir a la comunidad en el
futuro y, dado que la inmensa mayoría de usuarios no se dirige nunca a la
comunidad de desarrolladores, hay que tratar con especial atención a los
que sí lo hacen. Por ejemplo, cuando un usuario indica que una parte de la
documentación está incompleta se le puede proponer que la complete él
mismo y, cuando notifique un error, preguntarle si podría intentar resol-
verlo. Y, por supuesto, agradecer siempre su contribución, sea la que sea.
• Compartir�tareas�de�gestión: además del desarrollo del código, todo pro-

yecto lleva aparejadas una serie de tareas de gestión que, conforme el pro-
yecto crece, se vuelven más complejas. Los coordinadores o el equipo que
inició el proyecto suelen encargarse de ellas, pero es una buena práctica
compartirlas con otros miembros del proyecto, tal y como se ha visto en
el punto dedicado a la delegación. Entre estas tareas destacan:
– Gestión�de�parches. Controlar qué parches se han recibido y analizar-
los para aceptarlos o, en la mayoría de los casos, identificar sus proble-
mas y notificarlos al autor del parche.
– Gestión�de�traducciones. Coordinar la traducción de la documenta-

ción y del software.
– Gestión�de�documentación. Mantener la documentación al día e in-

tegrar las modificaciones conforme éstas van apareciendo, así como la
sección de preguntas frecuentes o FAQ.
– Gestión�de�errores. Gestionar la base de datos de errores, lo que inclu-

ye, entre otras funciones, asegurar su integridad y evitar la existencia
de errores duplicados.
• Gestionar� permisos. una de las tareas de gestión que merece mención

aparte es la gestión de los permisos o, en otras palabras, decidir quién tiene
permiso para realizar commits y por tanto puede integrar su código en la
copia remota del repositorio. Igualmente, la concesión de permisos impli-
ca también su posible revocación.
Los desarrolladores que no tienen permiso para realizar commits pueden,
por supuesto, contribuir al desarrollo del proyecto, realizando parches que
resuelvan errores o añadan nuevas funcionalidades y que serán analizados
por los desarrolladores del proyecto y finalmente incorporados. De hecho,
el mecanismo más habitual de obtención del permiso para realizar com-
mits es que un desarrollador contribuya con parches al proyecto, hasta que
el equipo de desarrolladores considere que sus aportaciones y su conoci-
miento del proyecto son suficientemente valiosos.
Para motivar la participación de nuevos desarrolladores, es conveniente
que el procedimiento de obtención del permiso para realizar commits sea
público y lo más transparente posible, así como su posible revocación.
3.3.5. Releasing y packaging
La preparación de las releases y el empaquetado o packaging son, junto con el

desarrollo del código, unas de las tareas más importantes que deben realizarse
en todo proyecto de software libre.
Una nueva release implica cambios, especialmente para los usuarios. En

primer lugar, todos los errores conocidos de la anterior release han si-
do solucionados y muy probablemente haya otros nuevos. Además, es
posible que haya funcionalidades y opciones de configuración nuevas.
Incluso puede que aparezcan incompatibilidades entre la nueva versión
del software y las anteriores, como por ejemplo en los formatos de los
datos.
Ya que el cambio de una release a otra puede tener consecuencias importantes,

y no todas positivas, uno de los primeros aspectos que se debe decidir es cómo
se va a identificar cada una de las releases.
Para ello hay un buen número de convenciones más o menos creativas, pero
lo más habitual es numerarlas con una serie de dígitos separados por puntos.
Por ejemplo:
• Release 3.4.1
• Release 3.4.2
• Release 3.5
• Release 4.0
El significado de los dígitos puede variar. Los cambios en el tercer dígito suelen
implicar soluciones a errores o pequeñas mejoras en algunas funcionalidades.
Los cambios en el segundo dígito suelen significar la introducción de nuevas
funcionalidades. Finalmente, los cambios en el primer dígito implican nuevos
grupos de funcionalidades y, probablemente, cambios importantes en lo que
respecta a la compatibilidad entre versiones.
Es conveniente indicar el significado de la numeración de las releases en el Página web

sitio web del proyecto.
Podéis consultar el esque-
ma de versiones del proyecto
Además, algunas releases se suelen identificar con la palabra alpha o beta, según APR (http://apr.apache.org/
versioning.html).
su estado de desarrollo. Por ejemplo:
• Release 3.4.1 (alpha 1)

• Release 3.4.1 (alpha 2)
• Release 3.4.1 (beta)
En general, la palabra alpha se utiliza para designar la primera release, la cual

permite que los usuarios accedan al software con todas las funcionalidades,
pero en el que se espera aún un buen número de errores. Los usuarios que
instalan y ejecutan una versión alpha suelen hacerlo para evaluar el software y
notificar los errores al equipo de desarrolladores. Una versión beta, en cambio,
está mucho más depurada y si casi no contiene errores se convertirá en la
versión oficial: es lo que se llama una versión candidata.
Para los desarrolladores, un proyecto de software libre está continuamente

en proceso de release, y utilizan siempre la última versión disponible en el
repositorio para su desarrollo, por lo que puede ser difícil capturar el momento
exacto de la release.
La mejor práctica para realizar esto es mantener una rama o branch en el re-
positorio que contenga el código que se introducirá en la próxima release, in-
dependientemente del tronco o trunk. De este modo, además, los desarrolla-
dores que no están involucrados en la preparación de la release pueden seguir
trabajando en el proyecto.
En consecuencia, una de las partes más importantes del proceso de prepara-

ción de una release es su estabilización, es decir, decidir qué cambios y funcio-
nalidades van a integrarse en la rama de la próxima release. Aquí, el mecanis-
mo de toma de decisiones de la comunidad de software libre debe ponerse de
nuevo en marcha y otra vez hay dos alternativas principales:
• Designar un propietario de la release, o release owner, que decide qué cam-

bios se van a introducir en la futura release.
• Votar los cambios que se van a introducir en la futura release, para lo cual
es necesario definir las reglas de la votación. Una solución intermedia es
fijar un número mínimo de desarrolladores que debe votar para que un
determinado cambio se incluya.
Además, se puede nombrar uno o dos release managers encargados de integrar

y validar los cambios en la rama de la release.
(69)
El software libre suele distribuirse como código fuente, adecuadamente empa- En sistemas GNU/Linux, la con-
69 vención es utilizar el formato TAR,
quetado y comprimido en un formato estándar . El nombre del paquete sue- comprimido por compress, gzip,
le estar formado por el nombre del paquete, el número de versión y el sufijo bzip o bzip2. En sistemas Windows
suele utilizarse el formato ZIP.
apropiado según el formato. Por ejemplo:
• miproyecto-3.4.1.tar.gz
• miproyecto-3.4.2.zip
Entre la información que debe acompañar a toda nueva release se incluye la

licencia bajo la cual se distribuye, las instrucciones de instalación y configu-
ración y los cambios y las novedades respecto a la última release70. Esta infor-
mación se recoge en una serie de archivos de número más o menos estándar:
LICENSE o COPYNG, README o INSTALL, y CHANGES.
(70)
Finalmente, el usuario debe realizar la compilación del código fuente y su ins- Por ejemplo, el sistema RPM
o DEB en sistemas GNU/Linux y,
talación en el sistema, que debe realizarse siempre de manera estándar si se
en sistemas Windows, los archivos
desea que el software llegue al mayor número de usuarios posible. Otra posi- MSI o ejecutables auto-instalables.
bilidad, empleada sobre todo con software ya maduro, es la distribución de

paquetes binarios, ya sea como ejecutables o instalables, que en cualquier caso
evitan que el usuario deba realizar el proceso de compilación manualmente70.
Desde el punto de vista de la empresa de software libre, la política de releases es

una de las herramientas más importantes para atraer a los usuarios potencia-
les del software. Una planificación adecuada de las releases debe dar respuesta
puntualmente a las necesidades de los usuarios, ya sea en nuevas funcionali-
dades como en la corrección de errores, por lo que debe encontrarse el ritmo
adecuado de publicación de las nuevas releases.
Por ejemplo, publicar nuevas releases con demasiada frecuencia puede saturar
al usuario, que probablemente no las instalaría todas y, al contrario, dejar pa-
sar demasiado tiempo entre releases podría hacer que el usuario buscara solu-
ciones alternativas. Del mismo modo, es conveniente asegurar la calidad de las
nuevas releases, intentando corregir la mayor cantidad de errores antes de su
publicación. El efecto de una release llena de errores da una imagen muy mala
del proyecto y de la empresa, que luego puede resultar difícil de enmendar.

Por ello, es especialmente importante apoyarse en el carácter abierto y coope-
rativo del software libre para mejorar su calidad.
3.3.6. Elección de licencias
Las diferencias, las ventajas y los inconvenientes de cada una de las licencias de
software libre es uno de los temas de discusión más recurrentes. Sin embargo,
lo cierto es que la elección de una u otra licencia tiene un papel menor en la
adopción y el éxito del proyecto, siempre y cuando ésta sea de software libre.
La inmensa mayoría de los usuarios elige una determinada solución según la
funcionalidad y la calidad que ofrece, pero no según su licencia.
(71)
Lo más importante es tener claro cuáles son los objetivos del proyecto y cuá- El anexo I proporciona una lis-
ta breve de las principales licencias
les son los objetivos de la empresa de software libre respecto al proyecto y,
utilizadas en la producción de soft-
en función de ello, elegir la licencia más adecuada o bien definir una nueva ware libre.
basada en las ya existentes71.

(72)
Por ejemplo, la licen-
cia OpenBravo (http://
Así, numerosos proyectos de software libre proporcionan su propia licencia, www.openbravo.com/product/le-
gal/license/) o la licencia dual de
adaptada a sus necesidades y objetivos72. MySQL (http://www.mysql.com/
about/legal/licensing/).
Las licencias de software libre, las relaciones y las incompatibilidades poten- Ved también
ciales entre ellas pueden resultar muy complejas y, en ocasiones, puede ser
La asignatura del máster oficial
necesaria la ayuda de abogados o juristas especializados. de Software libre, Aspectos le-
gales y de explotación del soft-
ware libre, profundiza en estos
Una de las principales fuentes de incompatibilidades es la reutilización de aspectos.
componentes libres bajo licencias restrictivas. Un ejemplo típico es la licencia
GPL, que obliga a que todo software que utilice componentes GPL sea a su vez
distribuido bajo licencia GPL.
Una buena práctica es la realización, desde el inicio del proyecto, de un inven-

tario o mapa del software externo y las licencias utilizadas en el proyecto, que
describa en qué partes del código se utilizan.
Resumen
A pesar de que la tecnología basada en software libre ha sido probada, se en-

cuentra en producción y funcionamiento en multitud de escenarios, y que
es fácil encontrar en los medios de comunicación generalistas noticias sobre
productos, eventos o personalidades relacionados con el software libre, siguen
existiendo un gran número de tópicos entorno a su implantación real y efec-
tiva.
Estos tópicos e ideas preconcebidas a menudo juegan en contra de la implan-

tación de sistemas basados en software libre, ya sea a nivel particular u orga-
nizativo. Desde el punto de vista del usuario, se suele decir que el software
libre es para expertos en informática o hackers, o que las aplicaciones basadas
en software libre son inestables, no están terminadas, o carecen del debido
soporte. Desde el punto de vista del empresario, se considera que el software
libre no protege suficientemente la propiedad intelectual, que representa una
pérdida de competitividad, o que salvo excepciones, no existen modelos de
negocio viables entorno al software libre.
En definitiva, la mayoría de estas ideas se pueden resumir en la falta de cali-

dad de los procesos y productos basados en software libre, y especialmente la
calidad percibida por el usuario. En cierta manera, no deja de ser cierto que la
propia historia, cultura y naturaleza del software libre y de la comunidad de
usuarios y desarrolladores, ha favorecido estas ideas.
El creciente compromiso de administraciones públicas y grandes organizacio-

nes con el software libre debería ayudar a reconsiderar la validez de estos pre-
juicios. Por otra parte, numerosos expertos y analistas destacan el potencial
del software libre para impulsar el desarrollo ecónomico tanto a nivel local
como europeo o mundial. Por ejemplo, según Gartner "el software libre es un
catalizador que va a restructurar la industria, produciendo software de calidad
superior a un coste más bajo".
Los materiales de esta asignatura pretenden dar respuesta a algunos de estos

tópicos, formando profesionales capaces de llevar a cabo proyectos de implan-
tación de sistemas de software libre a través del estudio detallado –desde un
punto de vista conceptual, metodológico y práctico– de este tipo de proyectos
en una variedad de escenarios y situaciones.
En general, cabe destacar que cualquier proyecto basado en software libre se

debe tratar en primer lugar como un proyecto de software y en segundo lugar
como un proyecto de ingeniería, por lo que los presentes materiales no pue-
den ni deben sustituir los conocimientos necesarios que són propios a estas
materias.
En este sentido, la mayor parte de los materiales se ha dedicado a estudiar los

conceptos, metodologías y herramientas necesarios para llevar a cabo proyec-
tos de desarrollo e implantación de software libre. Esto justifica el tratamien-
to generalista de algunos de los contenidos, aproximando progresivamente al
lector en las particularidades metodológicas de los proyectos basados en soft-
ware libre, tratando de ordenar y estructurar –de forma conceptual y funcio-
nal– las principales etapas e hitos de la implantación. Además, se ha presenta-
do cómo la actividad económica en torno al software libre, ya sea en forma de
desarrollo de software, consultoría, integración, implantación o soporte, pue-
de ser objeto de un modelo de negocio lucrativo, válido y viable. Del mismo
modo, y sin ser el objetivo principal de la asignatura, se han introducido los
aspectos esenciales que debe cubrir todo plan de empresa, y en concreto los
basados en software libre.
Sin duda, la constante evolución de las tecnologías y de los proyectos de soft-

ware libre dejará obsoleta al menos una parte de estos materiales, especialmen-
te aquella que hace referencia a proyectos y soluciones concretas. No obstante,
tanto la metodologia presentada como las referencias bibliográficas aportadas
deberían ayudar a encontrar la solución adecuada para cada proyecto o esce-
nario de implantación.
Por otra parte, se espera que la formalización y estructuración de las metodo-

logías y procedimientos presentados, así como la colección de buenas prácti-
cas en proyectos de software libre, supongan una aportación cualitativa para
la comunidad y para el desarrollo y expansión del software libre en general.
Finalmente, no se puede finalizar estas líneas sin agradecer a la Fundació de la

Universitat Oberta de Catalunya (http://www.uoc.edu) su apoyo en la elabo-
ración del presente material didáctico. Al mismo tiempo, se invita a todos los
lectores interesados en hacer llegar sus comentarios o sugerencias a ponerse
en contacto con los autores, a fin de mejorar tanto las futuras ediciones del
presente material como la práctica diaria en la implantación de sistemas ba-
sados en software libre.
Glosario
ciclo de vida de un proyecto m Proceso que engloba, estructura, organiza y coordina
todas las etapas y las fases que guían la ejecución de un proyecto y que permite afrontar la
complejidad de los objetivos reduciendo el riesgo de fracaso.
comunidad de software libre f Grupo de usuarios y desarrolladores de software libre.
DAFO m Acrónimo de "debilidades, amenazas, fortalezas y oportunidades" (en inglés,

SWOT). El análisis DAFO es una herramienta de planificación estratégica que se utiliza para
evaluar las debilidades, las amenazas, las fortalezas y las oportunidades relacionadas con un
proyecto.
estándar abierto m Formato o protocolo que está sujeto a la utilización y a la evalua-

ción públicas, que no depende de otros formatos o protocolos que no sean abiertos, que no
contiene cláusulas que limiten su utilización, que se gestiona independientemente de los
intereses particulares y que se encuentra disponible en diversas implementaciones (o en una
de acceso equitativo).
estudio de mercado m Análisis que se lleva a cabo dentro de un proyecto de iniciativa

empresarial con la finalidad de hacerse una idea de la viabilidad comercial de una actividad
económica, partiendo del entorno general, la competencia y los consumidores.
gestión de proyectos f Disciplina que estudia la manera óptima de organizar y adminis-

trar los recursos disponibles de forma que se pueda culminar toda tarea requerida en el pro-
yecto dentro del plazo, el tiempo y el coste definidos.
implantación de sistemas f Proceso mediante el cual se instauran una o más novedades

tecnológicas en una organización, como resultado de una actuación que deriva del plan
estratégico de la misma.
implantación directa f Proceso mediante el cual el sistema que debe instaurarse no re-
quiere una gran adaptación o configuración de los componentes involucrados.
infraestructura f Conjunto de elementos o componentes de base que, estructurados,

organizados y coordinados adecuadamente, facilitan el funcionamiento operacional de un
sistema.
insourcing Modelo estratégico que consiste en la delegación o la producción de operaciones

o trabajos en un departamento interno de la organización, normalmente especializado, en
lugar de subcontratarlos a un tercero externo a la organización.
licencia f Modelo contractual en el cual el autor del producto (o el poseedor de los derechos
de autoría) establece los derechos y los deberes de los usuarios del producto y el escenario
donde los pueden utilizar.
licencia libre de software f Licencia que garantiza los cuatro principios básicos libertad:
ejecutar el software con cualquier propósito, estudiar el código fuente y adaptarlo, redistribuir
copias del software, mejorar el código fuente y publicar las mejoras.
metodología f Análisis o estudio sistemático de los métodos y los procedimientos que son,
han sido o pueden ser aplicados a una determinada disciplina.
migración f Proceso de sustitución de unas infraestructuras basadas en software propieta-

rio por otras con funciones equivalentes basadas en software libre.
modelo de negocio m Estrategia empresarial que define, planifica, produce y comercializa

uno o más productos o servicios orientados al lucro de sus productores.
outsourcing Modelo estratégico que consiste en la delegación o la producción de opera-

ciones o trabajos en una organización externa a la organización, normalmente especializada,
en lugar de delegarlos a un departamento interno de la organización.
packaging o empaquetamiento m Proceso para automatizar la instalación, la configu-

ración y la desinstalación de los paquetes de software en un ordenador. En concreto, los sis-
temas GNU/Linux emplean habitualmente miles de paquetes diferentes.
plan estratégico de la organización m Conjunto de propuestas que definen los obje-

tivos o las tendencias de la organización en el futuro. Normalmente se desarrolla con poste-
rioridad en las diferentes áreas o departamentos funcionales de la organización.
software libre m Conjunto de programas y aplicaciones informáticas cuyas condiciones

de explotación se encuentran bajo una licencia libre.
proyecto m Proceso de gestión de recursos organizado, estructurado y planificado para

alcanzar un determinado objetivo, normalmente estratégico.
releasing o distribución m Proceso para hacer llegar la versión inicial o la actualización

de un producto de software a sus usuarios potenciales.
repositorio m Un repositorio, depósito o archivo es un lugar centralizado donde se alma-

cena y mantiene información digital, habitualmente bases de datos o archivos informáticos.
En el desarrollo de software libre, los repositorios incorporan un sistema de control de versio-
nes que mantiene el registro de todo el trabajo y los cambios en los archivos (principalmente
código fuente) que forman un proyecto y permite que diferentes desarrolladores (potencial-
mente separados por grandes distancias) colaboren.
riesgo m Acontecimiento probable que puede afectar a la marcha del proyecto y, eventual-
mente, impedir que se alcancen los objetivos a tiempo.
servicios del sistema m Conjunto de funciones que se pueden ejecutar, con o sin inter-
vención del usuario, y que se consideran esenciales para el funcionamiento de la organiza-
ción.
sistema m Conjunto de elementos o componentes independientes, físicos o lógicos, que

se relacionan entre sí para actuar como un conjunto integrado y funcional.
soporte al usuario m Conjunto de servicios que de manera integral, o a partir de diversos

medios de contacto, ofrece la posibilidad de gestionar y solucionar todas las posibles inci-
dencias ocasionadas durante la utilización de un programa o aplicación.
versión f Número que indica el nivel de desarrollo de un programa o aplicación.

Bibliografía
Abella, A.; Sánchez, J.; Santos, R., y otros (2003). Libro Blanco del software libre en
España. [Fecha de consulta: 01 de marzo de 2008]. http://www.libroblanco.com/document/
1000-2003.pdf
Abella, A.; Segovia, M. A. (2005). Libro Blanco del software libre en España (II).
[Fecha de consulta: 01 de marzo de 2008]. http://www.libroblanco.com/document/
II_libroblanco_del_software_libre.pdf
Abella, A.; Segovia, M. A. (2007). Libro Blanco del software libre en España
(III). [Fecha de consulta: 01 de marzo de 2008]. http://libroblanco.com/document/
III_libro_blanco_del_software_libre.pdf
Clearly, D. W.; Fenn, J.; Plumer, D. C. (2005). "Gartner's Positions on the Five Hot-
test IT Topics and Trends in 2005". [Fecha de consulta: 20 de mayo de 2008]. http://
www.gartner.com/DisplayDocument?doc_cd=125868
Díaz, R. M. (2007). El arte de dirigir proyectos (2a. ed.). Madrid: Ra-ma, 1995.
Guitérrez, J. D. (2007). Metodología para el análisis decisorio de la implantación de soft-

ware libre. [Fecha de consulta: 01 de marzo de 2008]. http://www.informaticahabana.com/
evento_virtual/files/SWL14.pdf
Hecker, F. (1998). "Setting Up Shop: The Business of Open-Source Software". [Fecha de con-
sulta: 01 de marzo de 2008]. http://www.hecker.org/writings/setting-up-shop.html
Kerchmer, K. (2005). "The Meaning of Open Standards". Proceedings of 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]
Sáez, D.; Peris, M.; Roca, R.; Anes, D. (2007). Migración al software libre. Guía de buenas
prácticas. Instituto Tecnológico de Informática.
SELF Project. URL: http://selfproject.eu [Fecha de consulta: 01 de marzo de 2008]
Free Software Foundation. URL: http://www.fsf.org/ [Fecha de consulta: 01 de marzo de 2008]
Vega García Pastor, I. de la (2004). El plan de negocio: una herramienta indispensable. Ins-
tituto de Empresa.
VV.AA. (2005). Migration guide. A guide to migrating the basic software components on server
and workstation computers (2005). Berlín: Bundesministerium des Innern. [Fecha de consulta:
20 de mayo de 2008]. http://www.kbst.bund.de/cln_012/nn_836802/SharedDocs/Anlagen-
kbst/Migrationsleitfaden/migration-guide-2nd-
edition__pdf,templateId=raw,property=publicationFile.pdf/migration-guide-2nd-
edition_pdf.pdf
Anexo
Anexo�I:�Licencias�libres�de�software
A continuación se presenta una lista breve de las principales licencias utiliza-

das para la producción de software libre. Algunas de ellas se presentan con
detalle en los materiales de las asignaturas de Introducción al software libre y
de Aspectos legales y de explotación del software libre (2ª parte).
GNU/GPL�v3
Las siglas GNU/GPL corresponden a la licencia General Public License del pro- Recurso web
yecto GNU.
Encontraréis más informa-
ción sobre la licencia GNU/
Mantiene una política de redistribución robusta, llamada copyleft, que esta- GPL en http://www.gnu.org/
licenses/gpl.html.
blece que todas las obras derivadas hereden la licencia original, incluso si se
han combinado con otras. No se permite el enlace desde módulos con una
licencia diferente. La política de protección de los derechos originales del au- Recurso web
tor y de la obra, entre otros, hace que la licencia GNU/GPL no sea compatible
Encontraréis una lista com-
con cualquier otra licencia, como por ejemplo la licencia BSD original o las pleta de compatibilidades en
licencias propietarias. http://www.gnu.org/licenses/
license-list.html.
La versión 3 de GNU/GPL no es directamente compatible con la versión 2. Sin

embargo, muchos programas licenciados bajo la segunda versión permiten la
utilización, en los mismos términos, de versiones posteriores de la licencia.
GNU/LGPL�v3
Las siglas GNU/LGPL corresponden a la licencia Lesser General Public License Recurso web
del proyecto GNU, una licencia derivada de GNU/GPL.
Encontraréis más infor-
mación sobre la licen-
Esta licencia se creó originalmente con el objetivo de permitir el uso, el enlace cia GNU/LGPL en http:/
/www.gnu.org/licenses/
y la integración de bibliotecas y librerías de software libre con otros tipos de lgpl.html.
licencia, en ocasiones propietarias, salvando las restricciones de las licencias
GNU/GPL. La práctica ha permitido licenciar un buen número de programas,
algunos de amplia difusión en la actualidad. Entre los programas licenciados
bajo GNU/LGPL figura el paquete ofimático OpenOffice.org.
La versión 3 de GNU/LGPL no es directamente compatible con la versión 2.

Sin embargo, muchos programas licenciados bajo la segunda versión permiten
la utilización, en los mismos términos, de versiones posteriores de la licencia.
Licencia�BSD
Las siglas BSD corresponden a la licencia Berkeley Software Distribution de la

Universidad de Berkeley.
Recursos web
Encontraréis más información de la licencia BSD en http://www.debian.org/misc/

bsd.license. También podéis encontrar un ejemplo de licencia derivada de la BSD origi-
nal en http://www.freebsd.org/copyright/freebsd-license.html, llamada licencia BSD de
dos cláusulas (2-clause BSD license) debido a la abolición de dos cláusulas de la licencia
original.
Forma parte de un grupo de licencias (BSD-style o BSD-like licenses, entre ellas

la licencia FreeBSD) denominadas permisivas, ya que mantienen una política
poco restrictiva con los derechos del usuario. Esta política, llamada copycenter
en oposición al término copyleft de las licencias GNU, permite entre otras
cosas la aplicación comercial del producto, su conversión a código propietario
y el enlace desde módulos con licencia diferente.
La licencia BSD original incorpora una cláusula de publicidad que la hace in-
compatible con GNU/GPL. La cláusula fue abolida en versiones posteriores,
dando lugar a la llamada BSD de tres cláusulas (en inglés, 3-clause BSD license),
compatible con GNU/GPL.
MPL�1.1
Las siglas MPL corresponden a la licencia Mozilla Public License de la Fundación Página web
Mozilla (Mozilla Foundation).
ción sobre la licencia MPL
Surgió de la iniciativa privada y es un híbrido entre las licencias BSD y GNU/ en http://www.mozilla.org/
MPL/MPL-1.1.html.
GPL. Está considerada una licencia permisiva semi-copyleft porque mantiene
alguna posibilidad de establecer licencias propietarias a partir de obras deri-
vadas. Permite el enlace desde módulos con licencia diferente. El artículo 13
permite licenciar una o más partes del código con una licencia diferente, lla-
mada alternativa. Sólo en caso de que la licencia alternativa sea GNU/GPL -o
cualquier otra de compatible-, la parte actuará como compatible con GPL, y
se podrá enlazar con otros que también lo sean.
Licencia�Apache�2.0
La licencia Apache es una licencia de la Fundación de Software Apache (Apache Página web
Software Foundation).
ción sobre la licencia Apache
Es bastante similar a la licencia BSD y está considerada permisiva porque man- en http://www.apache.org/li-
censes/LICENSE-2.0.
tiene la posibilidad de establecer licencias propietarias a partir de obras deri-
vadas, así como enlazarla desde módulos con licencia diferente. El uso de pa-
tentes de esta licencia y las provisiones de indemnización la hacen compatible
únicamente con la versión 3 de GNU/GPL, manteniendo la incompatibilidad
con las dos versiones anteriores.
Licencia�X11
La licencia X11, llamada erróneamente MIT License, es una licencia del Institu- Página web
to Tecnológico de Massachussetts (Massachussetts Institute of Technology, MIT).
ción sobre la licencia X11 en
Es bastante similar a la licencia BSD de tres cláusulas y está considerada per- http://www.opensource.org/
licenses/mit-license.php.
misiva porque permite licenciar obras derivadas como software propietario,
así como enlazarla desde módulos con licencia diferente. Es compatible con
GNU/GPL y está relacionada con el proyecto X.Org. En este sentido, algunas Página web
versiones antiguas de XFree86 la continúan utilizando, mientras que las ver-
siones más modernas utilizan la licencia XFree86 1.1, que es incompatible con ción sobre el proyecto X.Org
GNU/GPL debido a los reconocimientos que se imponen en toda la documen- en http://www.x.org/.
tación.
CDDL�1.0
Las siglas CDDL corresponden a la licencia Common Development and Distribu- Página web
tion License de SUN Microsystems.
ción sobre la licencia CDDL
Está basada en la versión 1.1 de la licencia MPL. Las diferencias principales se en http://www.sun.com/
cddl.
centran en dos aspectos:
• El autor (o el poseedor de los derechos de autoría) puede restringir la juris-

dicción legal de los derechos y los deberes de los usuarios del software.- El
autor (o el poseedor de los derechos de autoría) puede restringir la juris-
dicción legal de los derechos y los deberes de los usuarios del software.
• La licencia establece el requisito de identificar a todos los autores que con-

tribuyen a las modificaciones introducidas en las obras derivadas.
Permite el enlace desde módulos con otra licencia, así como licenciar los deri-
vados con una licencia diferente, eventualmente propietaria. Las característi-
cas relacionadas con la propiedad intelectual la hacen incompatible con GNU/
GPL.
CPL�1.0
Las siglas CPL corresponden a la licencia Common Public License de IBM. Página web

Su objetivo es promocionar el desarrollo de código libre, manteniendo la posi- ción sobre la licencia CPL en
bilidad de combinar el código con otras licencias, incluyendo licencias propie- http://www-128.ibm.com/
developerworks/library/os-
tarias, aunque impide licenciar los derivados con otro tipo de licencia. Tam- cpl.html.
bién prohíbe que el código derivado infrinja las patentes del original, ya que
obliga al pago de cualquier royalty. Es incompatible con GNU/GPL debido a
las cláusulas relacionadas con la legalidad de las obras derivadas.
És incompatible amb GNU/GPL degut a les clàusules relacionades amb la le-

galitat de les obres derivades.
EPL�1.0
Las siglas EPL corresponden a la licencia Eclipse Public License de la Fundación Página web
Eclipse (Eclipse Foundation).
ción sobre la licencia EPL en
Se basa en la licencia CPL y mantiene una política permisiva orientada al ne- http://www.eclipse.org/org/
documents/epl-v10.php.
gocio. La principal diferencia con respecto a CPL está en el tratamiento de las
infracciones de patentes por parte de los contribuyentes al software. Todo el
código licenciado bajo EPL mantiene la licencia en las obras derivadas. Sin
embargo, permite licenciar las adendas separadamente bajo otros tipos de li-
cencia, eventualmente propietarias. Permite el enlace desde módulos con li-
cencia diferente. Las características relacionadas con la permisividad de la obra
derivada y la gestión de la autoría la hacen incompatible con GNU/GPL.
Anexo�II:�Estándares�abiertos
Definición
El proyecto SELF define un estándar abierto como un formato o protocolo que:
• está sujeto a la utilización y la evaluación pública, sin apremios, y de forma Página web
equitativa para todo el mundo;
• no tiene ningún componente o extensión que dependa de formatos o pro- ción sobre los estándares
tocolos que no cumplan esta definición de estándar abierto; abiertos del proyecto SELF en
http://selfproject.eu/OSD.
• no tiene cláusulas técnicas o legales que limiten su utilización por cual-
quiera de las partes o en cualquier modelo de negocio;
• ha sido gestionado y desarrollado independientemente de los intereses co-
merciales particulares y mediante un proceso abierto y equitativo entre
competidores y terceras partes; y
• se encuentra disponible en múltiples implementaciones de diferentes ven-
dedores, o bien en una sola implementación disponible equitativamente
para todas las partes.
Sin embargo, no existe una definición única de estándar abierto, ya que cada Ejemplo
organización preconiza un conjunto de características o prácticas adecuadas
Como por ejemplo la defi-
a sus objetivos particulares. Estas organizaciones pueden ser organizaciones nición de la Unión Europea
de desarrollo de estándares, consejos supranacionales o gobiernos estatales. (http://europa.eu.int/idabc/
en/document/3761) o del
Algunas definiciones imponen la publicación en condiciones razonables y no ITU-T (http://www.itu.int/
ITU-T/othergroups/ipr-adhoc/
discriminatorias (en inglés, Reasonable And Non Discriminatory (RAND)), es de- openstandards.html).
cir, no totalmente exentas de royalties.
Otras definiciones inciden más en las características del proceso que debe se- Recursos web
guir un estándar para ser abierto, como por ejemplo las recomendaciones del
World Wide Web Consortium (W3C), de Bruce Perens o de Ken Krechmer. ción sobre estos procesos en:
http://www.w3.org/Con-
sortium/Process. http://
Organismos
perens.com/OpenStan-
dards/Definition.html.
http://www.csrstds.com/
Los principales organismos, asociaciones, institutos y consorcios relacionados openstds.pdf.
con los estándares de las tecnologías de la información son los siguientes:
ANSI (American National Standards Institute): el Instituto Americano de Están- Página web
dares Nacionales. Encontraréis más informa-

ción sobre ANSI en http://
www.ansi.org/.
ETSI (European Telecommunications Standards Institute): el Instituto Europeo de
Estándares de Telecomunicación (http://www.etsi.org/).
FreeStandards (The Free Standards Group): organización independiente que pro-

mueve la utilización y la aceptación de las tecnologías libres a través de están-
dares. (http://www.freestandards.org/.)
ICANN (Internet Corporation for Assigned Names and Numbers): Corporación de

Internet para la Asignación de Nombres y Números (http://www.icann.org/).
IEC (International Electrotechnical Commission): Comisión Internacional de

Electrotecnia (http://www.iec.ch/).
IEEE (Institute of Electrical and Electronics Engineers, Inc): Instituto de Ingenieros

Eléctricos y Electrónicos (http://www.ieee.org/).
IETF (Internet Engineering Task Force): Grupo de Trabajo en Ingeniería de Inter-

net (http://www.ietf.org/).
ISO (International Organization for Standardization): Organización Internacional

para la Estandarización (http://www.iso.ch/).
ITU (International Telecommunications Union): la Unión Internacional de Tele-

comunicaciones agrupa entidades de los sectores público y privado para coor-
dinar las telecomunicaciones y los servicios globales (http://www.itu.int/).
JXTA (JXTA Project): se trata de una combinación de estándares abiertos de

igual a igual (en inglés, peer-to-peer o P2P) con implementaciones abiertas a
Java. (http://www.jxta.org/)
OASIS (Organization for the Advancement of Structured Information Standards):

es un consorcio internacional sin fines de lucro que orienta el desarrollo,
la convergencia y la adopción de los estándares e-business (http://www.oasis-
open.org/).
OpenGroup (The Open Group): es un consorcio internacional de vendedores

para el avance neutral de la tecnología (http://www.opengroup.org/).
RossettaNet (Open e-business process standards): es una asociación para favore-

cer los estándares abiertos en el e-business (http://www.rosettanet.org/).
VoiceXML (Voice XML Forum): es una organización de industrias para

crear y promover el Voice Extensible Markup Language (VoiceXML) (http://
www.voicexml.org/).
W3C (World Wide Web Consortium): es un consorcio mundial para promover

los estándares en Internet (http://www.voicexml.org/).
WS-I (Web Services Interoperability Organization): Organización para la Intero-

perabilidad de Servicios Web (http://www.ws-i.org/).
Estándares�abiertos
A continuación se enumeran los principales estándares abiertos identificados

por el proyecto SELF (http://selfproject.eu/en/system/files/D1_WP2.pdf).
• Texto�no�formateado
ASCII, ISO8859 (http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=28245) y UNICODE (http://
www.unicode.org/).
• Texto�con�formato
ODT (Open Document Text) y DocBook (http://www.oasis-open.org/com-
mittees/tc_home.php?wg_abbrev=office).
• Texto�científico
ODF (Open Document Formulae), MathML (Mathematical Markup Language)
(http://www.w3.org/Math/) y TeX/LaTeX (http://www.tug.org/) y (http://
www.latex-project.org/).
• Imágenes�(tramas)
JPEG (Joint Photographic Expert Group) (http://www.jpeg.org/) y (http://
www.w3.org/Graphics/JPEG/), PNG (Portable Network Graphics) (http://
www.libpng.org/pub/png/) y (http://www.w3.org/Graphics/PNG/), PNM
(Portable Any Map) (http://netpbm.sourceforge.net/doc/pnm.html), GIF
(Graphics Interchange Format) (http://www.w3.org/Graphics/GIF/spec-
gif89a.txt), BMP (Bitmap) (http://atlc.sourceforge.net/bmp.html).
• Imágenes�(vectores)
SVG (Scalable Vector Graphics) (http://svg.org/) y (http://www.w3.org/
Graphics/SVG/), ODG (Open Document Graphics).
• Video
OpenEXR (http://www.openexr.com/), Theora (http://theora.org/), RIFF
(Resource Interchange File Format) (http://msdn2.microsoft.com/en-
us/library/ms713231.aspx), AVI (Audio Video Interleave) (http://
msdn2.microsoft.com/en-us/library/ms779636.aspx).
• Impresión
PDF (Portable Document Format) (http://www.adobe.com/devnet/
pdf/), PS (PostScript) (http://partners.adobe.com/public/developer/ps/
index_specs.html).
• Hipertexto
HTML (Hyper Text Markup Language), XHTML (Extended Hyper Text Markup
Language) (http://www.w3.org/MarkUp/).
• Presentación
ODP (Open Document Presentation).
• Audio
Vorbis (OGG Vorbis) (http://www.vorbis.com/) y (http://xiph.org/
), FLAC (Free LossLess Audio Codec) (http://flac.sourceforge.net/)) y
(http://xiph.org/), RIFF, WAV (Wave) (http://www.borg.com/~jglatt/tech/
wave.htm).
• Educació�i�aprenentatge
LOM (Learning Object Metadata) (http://zope.cetis.ac.uk/profiles/
uklomcore), SCORM (Sharable Content Object Reference Model)
(http://www.conform2scorm.com/), IMS (http://www.imsglobal.org/
commoncartridge.html), LD (Learning Design) (http://www.imsglobal.org/
learningdesign/index.html).
• Empresa
XBRL (Extensible Business Reporting Language) (http://www.xbrl.org/).

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

Implantación,

1. Introducción a la implantación de sistemas basados en

2. El proyecto de software libre..................................................... 37

2.3. Estudio de los requisitos de la implantación ............................ 48

3. La empresa del software libre.................................................... 104

3.2.6. Estudio de mercado ....................................................... 125

En este módulo nos adentraremos en la metodología propia de la implanta-

En la actualidad, la tecnología se posiciona como factor estratégico dentro de

En este sentido, la implantación de sistemas no se puede dejar al azar o a la

El objetivo central de este módulo es ofrecer una visión amplia y detallada de

Los contenidos de este módulo se estructuran en tres unidades, que presentan

exponen la implantación de sistemas desde la perspectiva del software libre,

El primer apartado, "Introducción a la implantación de sistemas", se dedica a

El segundo apartado, "El proyecto de software libre", se dedica a presentar de

Esperamos que la formalización conceptual, metodológica y práctica de los

Los objetivos de este módulo siguiente son los siguientes:

1. Conocer los conceptos fundamentales de la implantación de sistemas ba-

2. Saber identificar los diferentes tipos de proyectos de implantación de sis-

3. Familiarizarse con las áreas de gestión de proyectos y sus particularidades

4. Conocer los elementos principales de un proyecto de software libre.

5. Conocer las fases del ciclo de vida de un proyecto de software libre.

6. Aprender a preparar una propuesta de proyecto de software libre.

7. Conocer en detalle las características de un proyecto de migración a soft-

8. Aprender a planificar y ejecutar un proyecto de migración a software libre.

9. Conocer los modelos de negocio utilizados por las empresas de software

10. Familiarizarse con los elementos principales de un plan de empresa o ne-

11. Aprender a crear un plan de empresa o negocio basado en software libre.

12. Conocer las características principales de la producción de software libre

1. Introducción a la implantación de sistemas basados

Este primer módulo de la asignatura de Implantación de sistemas de software

El módulo se inicia con un repaso de los conceptos básicos de los proyectos

Después, se presenta una clasificación de los tipos de proyectos de implanta-

Una vez se han revisado los conceptos básicos de la implantación de sistemas y

Finalmente, se repasarán los conceptos básicos de la gestión de proyectos y

1.1. Conceptos básicos

En este primer apartado repasaremos los conceptos básicos de la implantación

Históricamente, la implantación de sistemas siempre ha estado estrechamente

El hecho de corresponder a una implantación tecnológica implica la conside-

En este sentido, la implantación de sistemas es el proceso por el cual

De acuerdo con esta definición, la implantación de sistemas tecnológicos de-

Se puede ilustrar este concepto con dos ejemplos de ámbitos diferentes:

• Una administración pública, en tanto que organización sin ánimo de lu-

1.1.2. El plan estratégico de la organización

En el anterior apartado se ha hecho referencia al plan estratégico de la organi-

El plan estratégico de la organización es un conjunto de propuestas que

nización en su entorno, en un momento dado.

El plan estratégico de la organización evoluciona con el tiempo, adaptándo-

1.1.3. Origen de la implantación de sistemas

En los párrafos anteriores hemos visto el vínculo existente entre el proyecto

Así pues, la implantación de un sistema requiere haber constatado ca-

A grandes rasgos, se pueden considerar cuatro orígenes genéricos que pueden

• Detección� de� problemas: puede haber casos diversos de mal funciona-

• Evolución�del�sistema: se trata de situaciones de obsolescencia funcional

En estos casos, el plan estratégico se ve afectado por la pérdida de eficacia

• Mejora�del�sistema: se trata de situaciones de obsolescencia estructural del

• Nueva�actuación�estratégica: encontramos las posibles actualizaciones,

La lista de posibles orígenes presentada en los párrafos anteriores no es exhaus-

1.1.4. Recursos de un proyecto de implantación de sistemas

Uno de los puntos importantes del proyecto de implantación, independiente-

Normalmente, el comité de supervisión está formado por personas de las di-

El rol de los recursos en la implantación de un sistema es doblemente impor-

• Por una parte, porque de la asignación de los recursos humanos dependerá

• Por otra parte, porque de la asignación de recursos materiales dependerá