Este documento describe un proyecto para liberar el software SIGATI desarrollado por la Universidad Católica de Brasil como software libre. Actualmente, el software se desarrolla de forma cerrada. El proyecto busca planificar la liberación del código fuente, documentación y procesos de desarrollo para crear una comunidad en línea alrededor del software. Se analiza la infraestructura técnica existente y los requisitos legales, operativos y económicos para la liberación con éxito del software.

1. PEC3 – Proyecto de Gestión de Sistemas de Información en
Entornos de Software Libre
Mauro Tapajós Santos
Liberación de software: Se trata de estudiar la viabilidad y presentar el plan de desarrollo de la
liberación de un proyecto de software o de todo el software desarrollado por una organización. Pueden
haber variantes, según sea la organización una administración pública o una empresa. En este caso, es
una universidad.
Proyecto - Descripción
Estudiar y planificar la liberación del software libre SIGATI:
Participé yo de un proyecto de investigación (CESMIC www.cesmic.ucb.br) en mi universidad
(Universidad Católica de Brasília – www.ucb.br) que tuvo financiación de una empresa (ITAUTEC –
www.itautec.com.br) bajo una ley brasileña de incentivo a la investigación. Desarrollamos un software
que iba a ser propuesto como alternativa a el software propietario que es utilizado en el SERPRO
(www.serpro.gov.br), un órgano que actúa en la área de TI del gobierno de Brasil. SERPRO tuvo
interese en este desarrollo y podría ser uno de los divulgadores de él en el gobierno de Brasil.
GATI es un sistema de gestión de entornos de TI. Él se compone de un servicios de directorios LDAP
(el OpenLDAP) con su administración toda centralizada y hecha por la WEB. Incluso las tareas de
creación de replicas, particiones, a parte de tratar los objetos comunes como usuarios y grupos.
Además, GATI puede ofrecer en la misma interface WEB la gestión de servicios de red, como los de
distribución de aplicaciones vía red, controle de impresión, ejecución de scripts, autenticación,
controlados por él a través de los objetos en la base de datos LDAP. Nuevos servicios pueden ser
añadidos utilizando la misma infraestructura.
Ahora planease lanzarlo como SL en Internet y presentar CESMIC como opción de servicios con él.
Esta idea de proyecto sería planear como liberarlo, los aspectos legales, las partes relacionadas
(universidad, empresa) y el soporte necesario a se crear en Internet una comunidad alrededor de él.
Estudio de Viabilidad
Necesidades planteadas:
– Abrir la aplicación GATI para una posible comunidad Internet y de manera a garantizar su futuro
como software libre.
– Hacer disponible en Internet una versión estable y versiones de desarrollo de forma que los
usuarios puedan elegir cual es la más apropiada de acuerdo con su tarea (desarrollo, produción,

2. etc).
– Hacer todo lo necesario con cuidado para que no haya ningún problema legal ya que se trata de el
resultado de esfuerzos de la Universidad y de las citadas empresas.
– Utilizar preferiblemente la infraestructura de servidores y Internet que hay en el proyecto
CESMIC.
– La tecnología de los softwares que serán elegidos a se utilizar en el proyecto: totalmente libres.
– Dimensionar el equipo que va a coordinar la evolución del desarrollo.
Alcance del proyecto:
El proyecto tratará de todo relacionado con la liberación del software:
• Aspectos legales involucrados: licencias, documentos, posibles problemas legales, etc.
• Los servidores y sistemas necesarios a la comunidad y sus funciones.
• Partir del proceso actual de desarrollo para lo que se va a establecer con la comunidad, y tener
todo documentado en la WEB para acceso público.
Estudio de la situación actual:
GATI ha sido desarrollado según el modelo cerrado de forma que nadie podría tener acceso a él con
excepción de los que lo desarrollabam (SERPRO, integrantes del proyecto CESMIC, etc). El lab
CESMIC fue usado para eso. El CESMIC tiene una LAN en la que hay una conexión en directo con
Internet a través de una dirección de IP válida. Un firewall Debian GNU/Linux sarge mantiene el
control y seguridad de la LAN.
Las decisiones sobre el desarrollo se resolvían a través de reuniones de CESMIC con Itautec, según
los requisitos que SERPRO se les daba.
En esta situación fue creada una infraestructura de servidores y sistemas que atendían a las
necesidades de desarrollo:
• Sistema de Control de Versiones: 1 servidor CVS (FC2) – Repositorio de código fuente –
mantenido por un profesor de UCB.
• Sistema de Contenido (Documentación): 1 servidor de contenido WEB ZOPE/PLONE –
mantiene una página del proyecto pública sólo con informaciones generales y manuales en PDF
para los que trabajan con él. Hay una parte que se accede a través de usuario/contraseña donde
están todos los documentos relativos al proyecto – está mantenido por un profesor de UCB y las
contribuciones son de todos los que desarrollaban GATI (Debian sarge).
• Sistema de Copias de Seguridad: 1 servidor de backup en disco duro por red ssh (Debian sarge),
mantenido por un becario de CESMIC/UCB.
• Sistema Firewall: 1 servidor actuando como firewall iptables (Debian sarge) para la Internet y la
rede de UCB, mantenido por un profesor CESMIC/UCB.

3. • 6 servidores en los que desarrollaba y hacían pruebas del software (distro Red Hat, FC),
mantenidos por los que lo utilizan.
• 7 estaciones para los desarrolladores (distros FC, Debian, Open SUSE).
Con el fin del convenio con Itautec, los afectados por los sistemas que se va a implantar son:
• El proyecto de investigación CESMIC.
• La Universidad Católica de Brasília.
• La nueva comunidad que se va a crear para GATI (usuarios existentes y futuros).
Diagnóstico de la situación actual:
• Sistema de Control de Versiones: está activo y disponible en Internet, aunque protegido por el
firewall, pero no se puede bajar el código como usuario anónimo. Además, el servidor está en una
versión ya desactualizada de SO (Fedora Core 2). Así que hay que actualizarla. La versión que
está allá no será la que será publicada. Hay que debatir eso con el equipo de desarrolladores.
• Sistema de Contenido (Documentación): el SO del servidor PLONE también está
desactualizado (FC2). Hay que actualizarlo y migrar a los datos para una nueva versión de
PLONE.
• Sistema de Copias de Seguridad: ya está actualizado con Debian Sarge. Se necesitarán arreglar
los comandos de backup y directorios donde hacer las copias de seguridad según las nuevas
instalaciones que se llevarán a cabo.
• Sistema de Firewall: ya está actualizado con Debian Sarge y las actualizaciones de seguridad. Es
mantenido por CESMIC, protegiendo a la rede interna.
• 6 servidores en los que desarrollaba y hacían pruebas del software (distro Red Hat, FC): estos
servidores seguirán siendo utilizados por el equipe de desarrollo de CESMIC y no tendrán, por lo
menos inicialmente, acceso externo.
Requisitos:
a) Técnicos
• Ofrecer a la comunidad un sitio WEB (pagina del proyecto) con enlaces a un repositorio de código
fuente CVS donde se pueda acceder a los fuentes y se pueda hacer el controle de versiones y un
servidor que tenga los paquetes de código y instalación listos para descarga (100).
• Además, ofrecer un espacio de documentación preferiblemente online por la WEB. La idea es
utilizar a un Wiki, con enlaces desde la página del proyecto (70).
• Implementar un proceso de backup eficiente para el código y documentación del proyecto (90).
• Ofrecer una lista de correo para permitir el debate, dudas y discusión sobre el proyecto (90).

4. • Ofrecer un sistema de bugtracking para registro de errores y su historio (90).
• Preferir plataformas de SO libres estables, preferiblemente Debian Sarge, para sostentar a los
servicios (100).
b) Operativos
• Crear un proceso de desarrollo para el proyecto donde se tenga claro las condiciones de obtener el
código y de ofrecer contribuciones a él (código y documentación). Además, hay que planear su
coordinación de manera que haya alguien o grupo que sea responsable en agregar y lanzar la
versión estable y mantener el trabajo en la de desarrollo (100).
• Permitir que se contribuya al proyecto cualquiera de manera fácil a través de infraestructura WEB,
tanto en la documentación, como en el desarrollo de código (90).
• Establecer un adecuado ritmo de lanzamiento de versiones para la comunidad de forma segura
(80).
c) Legales
– Cambiar el nombre del software. Eso tiene implicaciones con los temas de marcas y dominios
Internet, pues el nombre GATI si que ya lo tienen registrado en Brasil (100).
– Establecer cual será su licencia libre y modo de utilización bajo la legislación de Brasil. Se
supone que la licencia lo permita su utilización bajo contextos “libres” y comerciales, pero sin que
el código se quede cerrado por cualesquiera motivos (80).
d) Económicos
– Como cualquiera proyecto de SL, cierta financiación es necesaria para empezar. La idea es utilizar
los recursos que ya existían para CESMIC para que se arranque el proyecto. Así que los requisitos
económicos siguen por las limitaciones que CESMIC tiene. Existen servidores en los que se
podría poner los mencionados sistemas. Por supuesto, las personas las que podrían trabajar en el
sistema son los profesores y los becarios del proyecto, utilizando sus horas de él (100).
– Este “aporte” de CESMIC sí que puede ser considerado como inversión del proyecto y de UCB.
Se espera obtener ingresos con la oferta de servicios que CESMIC ofrecerá al mercado como
consultorías y capacitación, de forma que haya bueno ROI a este esfuerzo y que la iniciativa siga
con sus propias piernas (70).
Soluciónes posibles para cada uno de los componentes de la solución – Alternativas y Valoración
1) Sítio WEB ­ Sistema de controle de versiones
a) Utilizar a PLONE que ya existe en CESMIC y poner todo el código en su base de datos

5. Comentarios: El sitio PLONE que existe en CESMIC tiene otro objetivo que es mantener la
documentación de este proyecto y eso puede significar otras líneas de investigación las que hay
en CESMIC. Por supuesto, los usuarios y privilegios que hay allá no serán los mismos del
proyecto de que tratamos (GATI). Con eso habrán los riesgos de la mala configuración de
aquellos. Sin embargo, el procedimiento de backup sería más sencillo pero saldría como que
casi imposible separar el contenido de CESMIC de lo del proyecto GATI.
b) Utilizar al PLONE de CESMIC como sitio inicial y luego tener enlaces para un repositorio
externo en otro servidor.
Comentarios: Aunque el código no esté en PLONE de CESMIC si que su página inicial estaría.
Los posibles problemas de mala configuración y separación de las partes seguirían.
c) Utilizar una infraestructura externa para proyectos de SL con las de Sourceforge o Código Livre
(en Brasil – www.codigolibre.org.br) ya con todo: sitio WEB y repositorio de código y paquetes
preparados.
Comentarios: La opción de sitio y repositorio externo hace con que el proyecto se torne
totalmente independiente de CESMIC luego ninguna infraestructura de servidores sería
necesaria en CESMIC, pero el proyecto estaría todo ubicado en un servicio público.
2) Sistema de documentación
a) Utilizar a PLONE de CESMIC, al final ya es un servidor de contenido.
Comentarios: Lo mismo comentado antes se pasa nuevamente. Existe la posibilidad muy fuerte
de que las configuraciones de usuarios y privilegios se las hacen complejas y hayan equívocos.
La separación de los contenidos también puede ser un problema futuro. Hay que tener en
cuenta que PLONE exige muchos recursos de la máquina por que se trata de una solución de
grande porte.
b) Utilizar a un Wiki.
Comentarios: esta opción podría crear un entorno de documentación sólo para el proyecto, de
forma que la documentación siempre esté online y actualizada por todos. Además, los sistemas
wiki no consumen tantos recursos de la máquina y suelen permitir la exportación de sus datos
de varias formas, incluso HTML y texto puro, lo que sería interesante en un posible futuro
cambio de solución. Hay muchos wikis pero las opciones consideradas acá son las de Twiki y
Mediawiki por que ya son conocidas de los integrantes del proyecto.
3) Sistemas de copias de seguridad ­ Backup
a) Utilizar al mismo que ya está funcionando en CESMIC.
Comentarios: ese sistema se lo considera de soporte. Si su configuración es tranquila para
nuevos servidores, entonces utilizarlo sería muy fácil.
b) Crear un nuevo independiente de lo que existe en CESMIC
Comentarios: como se trata de sistema de soporte, no es necesario crear todo un nuevo sistema

6. para una actividad complementaria si él ya existe.
4) Lista de correo e sistemas de bugtracking
a) Crear un servidor con el software de Mailman (www.gnu.org/software/mailman/index.html)
para listas de correo y de bugzilla (www.bugzilla.org/) o TRAC (trac.edgewall.org/) para
bugtracking.
Comentarios: La ventaja sería tener control de él todo en CESMIC. Sin embargo, hay que
mantenerlos los servicios lo que conlleva a obligaciones operativas (horas, servidores) por parte
del proyecto.
b) Utilizar la existente estructura de listas de correo de UCB (servidor Mailman en UCB).
Comentarios: si existe podría ser utilizado. No obstante, la estructura estaría en la Universidad y
bajo su operación, y que haya riesgos de paradas del servicio.
c) Utilizar a una infraestructura externa para los dos como las citadas arriba en el ítem 1.
Comentarios: se tendría todo afuera del lab CESMIC. Sin embargo todo depende de la
disponibilidad del servicio público y a los riesgos de su ausencia.
Selección de la Solución
Después de haber descritas las alternativas y sus comentarios, se propone los siguientes sistemas,
según calificaciones de impacto, inversión, riesgos y la madurez de los softwares propuestos. Notese
que la liberación del software tiene el objetivo de divulgación de “expertise” de investigación en
LDAP e servicios de red controlados por un servicio de directorio LDAP, pero con posible futura
contratación de servicios de CESMIC.
La idea es que los sistemas en los que se atribuye descarga pesada de ficheros estarán en lo posible
afuera de CESMIC. Esto se debe por que las descargas de los paquetes de código y los manuales si
que pondrían abajo la conexión del lab con Internet. Así que sólo la página WEB del proyecto se
quedaría en CESMIC en un nuevo servidor WEB Apache en Debian, dónde ya está el PLONE de
CESMIC, pero en un dominio WEB en separado. Sus enlaces pues apuntarían a los repositorios
externos de Código Livre donde se quedarían los paquetes binarios de instalación y de código fuente,
y los manuales.
El código fuente por su vez estaría en otro servidor CVS en CESMIC con acceso externo a través del
firewall y con la posibilidad de descargas del código como anónimo. Para los desarolladores de la
comunidad habrá la posibilidad de commits en la versión de desarrollo bajo la supervisión del
coordinador del proyecto. Él definirá cuales de los contribuyentes podrán hacer los commits.
La documentación especifica del proyecto estaría en un wiki, también creado internamente en
CESMIC. Eso se elige para que la documentación sea independiente de la del proyecto CESMIC y
pueda ser fácilmente convertida en otros sistemas a través de exportación por HTML o TXT.
Las copias de seguridad pueden ser hechas por el servicio existente para el sitio WEB y los fuentes ya
que todos estos elementos estarán en la estructura interna del lab. Los paquetes binarios y de fuente

7. pueden ser recreados a partir del código fuente en CVS así que no se lo hacen copias de seguridad.
Se mantendrán los papeles de coordinadores para cada uno de los módulos de SIGATI en el arranque.
Pero inicialmente éste será probablemente la misma persona. En el futuro se podría debatir la opción
de tener coordinadores (personas distintas) para cada modulo. Sin embargo, para empezar sólo un
coordinador será necesario. Además, ningún proyecto de SL tiene aportaciones inmediatas a su
liberación, así que no se esperan contribuciones inmediatas tras su publicación.
El servidor de bugtracking sería creado como nuevo y su mantenimiento sería de CESMIC. Se
utilizará el software bugzilla sobre plataforma Debian Sarge. Eso se debe al conocimiento existente en
esta opción por parte de los integrantes del proyecto. Además él es muy conocido por la comunidad
de software libre, lo que facilitaría su uso. Es posible abrir reglas en el firewall para que conexiones
externas puedan llegar a él y a los otros sistemas que tienen que tener acceso externo.
Por fin, sería creada una lista de correo de GATI en los servidores de UCB. Este servicio actualmente
ya roda sobre plataforma de software libre igual a que se utilizaría para construir un en CESMIC
(mailman). Por la proximidad con el operativo de la universidad, ocurre que los riesgos no serían tan
distintos de la opción de tenerlo todo en CESMIC.
Nombre del Software
Sobre el tema del nombre del software, su nuevo nombre será SIGATI y adelante sólo se refiriera a él
así. La versión divulgada por Itautec tiene ahora el nombre de “Librix AD”, pero como ha sido dicho,
tratase de un “fork” del desarrollo y se tornaran productos completamente distintos y independientes.
Análisis del Sistema
Definición de los sistemas involucrados en la liberación del software
Después de haber listado todos los sistemas involucrados en la liberación de SIGATI, hay que tener en
cuenta que los siguientes sistemas ya existen o serán apenas actualizados o su creación es demasiada
sencilla y no será considerada en detalles en este proyecto:
– Sistema de backup – sólo exige añadir configuración para contemplar a los nuevos servidores.
– Sistema CVS de código fuente interno de CESMIC – ya existe. Tendrá su SO actualizado.
– Sitio externo de “Código Livre” ­ mantendrá apenas las descargas de ficheros de paquetes del
software y sus manuales. Exigirá apenas la creación de la nueva cuenta, su configuración y upload
de los ficheros.
– Lista de correo – como será creada en los servidores de UCB, su creación demandará esfuerzo
mínimo.
– Página WEB inicial del proyecto – será creado un fichero HTML y será puesto en el servidor
WEB Apache que ya ejecuta el sitio WEB de CESMIC. Cuidado será tomado en mantenerlo en un
nuevo subdominio de CESMIC (sigati.cesmic.ucb.br).

8. Debido a las limitaciones de tiempo para la entrega de este proyecto, nos centraremos exclusivamente
en los dos sistemas restantes de:
– Documentación (Wiki)
– Bugzilla
dentro del contexto de los demás sistemas citados.
Requisitos Exactos
• Ofrecer a la comunidad SIGATI un sistema de documentación adecuado al proyecto y que se lo
permita crecer la documentación a través de colaboración de los miembros internos de SIGATI y
los demás de la comunidad.
• El sistema de documentación debe permitir controle online con usuarios y contraseñas sobre las
diversas partes de la documentación.
• El sistema de documentación debe permitir la fácil exportación de sus datos para los formatos
HTML y texto puro.
• El sistema de documentación debe ser de fácil instalación para la distribución Debian, la distro
utilizada en el proyecto.
• Ofrecer a la comunidad SIGATI un sistema de gestión de errores y histórico de ellos adecuado al
proyecto y que se lo permita registrar las fallas encontradas por los miembros de la comunidad.
• El sistema de gestión de errores debe permitir controle con usuarios y contraseñas para los
registros de errores.
• El sistema de gestión de errores debe permitir exportación de su base de datos con fines de
backup. Su periodicidad será de 1 semana.
• Crear un proceso de desarrollo asociado a los sistemas para el proyecto donde se tenga claro las
condiciones de obtener el código y de ofrecer contribuciones a él. Además, hay que planear su
coordinación de manera que haya alguien o grupo que sea responsable en agregar y lanzar la
versión estable y mantener el trabajo en la de desarrollo.
• Permitir que se contribuya al proyecto cualquiera de manera fácil a través de infraestructura WEB,
tanto en la documentación, como en el desarrollo de código.
• Establecer cual será la licencia libre se SIGATI y su modo de utilización bajo la legislación de
Brasil. Se supone que la licencia lo permita su utilización bajo contextos “libres” y comerciales,
pero sin que el código se quede cerrado por cualesquiera motivos.
• Tener en cuenta cualesquiera porción de software adjunto a SIGATI con licenciamiento distinto de
lo que se va a aplicar a SIGATI, y garantizar que las clausulas de sus licencias no se van a
contradecir por la licencia aplicada a SIGATI.

9. • Garantizar que el gasto de licencias con software para los servidores (SO y aplicaciones) sea nulo
(siempre softwares libres)
Entorno Tecnológico
• Sistema operativo de todos los servers: Debian estable GNU/Linux (sarge 3.1).
• Todos los servidores estarán ejecutando su SO solamente en modo texto y con lo mínimo número
de procesos posible (seguredad).
• Sistema de documentación: Twiki 3
• Sistema de gestión de errores: Bugzilla 2.20
• Puede ser necesario la adecuación de aspectos de la instalación de los sistemas arriba. Para eso se
utilizará hasta posible shell scripts Bash y los ficheros de configuración relacionados.
• El proceso de backup de los servicios descritos ya es automatizado en otro servidor y hace las
copias a través de la red por ssh.

10. Figura 1 – Descripción general de la infraestructura a ser hecha disponible para el proyecto SIGATI
Definición de estándares y normas
Para la implantación de los sistemas, se seguirán las normas de instalación de servidores Debian
estable en CESMIC y estarán bajo las reglas de seguridad aplicadas en este lab.
Toda la documentación sobre los servidores y sus configuraciones estará en formato PLONE y
localizada en el portal del proyecto CESMIC.
Participación de los usuarios
Para asegurar que los requisitos de diseño estén correctamente cubiertos, es indispensable la
participación de las siguientes personas en la organización:
● Coordinador de cada módulo de SIGATI
● Coordinador de la documentación
● Desarrolladores SIGATI (inicialmente profesores y becarios de CESMIC)
● Generadores de documentación (usuarios internos y externos a CESMIC)
● Comunidad SIGATI
● Administradores de los servidores siendo montados
Establecimiento de requisitos
Requisitos Funcionales
• Debe existir módulos de documentación para cada uno de los módulos de SIGATI de forma
independiente, con grupos y usuarios en separado.
• Cada aportación de documentación deberá ser revisada por el coordinador del módulo de SIGATI
y luego el coordinador de la documentación la pondrá disponible.
• Debe ser fácil la exportación de un módulo de documentación en separado en formato TXT o
HTML.
• El lenguaje a ser utilizado en los documentos del wiki debe ser fácil para usuarios comunes
(lenguaje de tags o HTML en Twiki).

11. • La actual documentación debe poder ser importada en el wiki.
• Cada registro de bug en el sistema de gestión de errores debe ser debidamente catalogado en lo
módulo de SIGATI correspondiente junto con las demás informaciones del bug.
• La base del sistema de gestión de errores debe ser exportable y permitir reports por mes.
Requisitos de Seguridad
• Se debe poder conocer quien y cuando se documentó algo.
• Lo mismo para el registro de bugs.
• La base de datos de bugs debe estar segura, se posible en otro servidor que no el de la aplicación
WEB.
Requisitos de Implantación
• Será hecha en paralelo en el actual entorno de producción lo cual será adecuado para en nuevo
conjunto de sistemas de apoyo al desarrollo de SIGATI.
• La actual documentación será importada luego se tenga el sistema de documentación listo para
contribuciones.
Requisitos de Disponibilidad
• Los dos sistemas deberán permitir accesos simultáneos de manera que los usuarios no tengan que
interrumpir su trabajo durante la ejecución de procesos por parte de otros usuarios.
Casos de uso
Caso de uso 1 ­ Aporte de documentación por parte de usuarios

12. Figura 2 – Caso de uso 1
Cada usuario (generador de documentación) debe registrarse en el sistema antes de aportar
documentación. Su id será utilizada para los logs de cada aporte.
A través de la interface WEB, él puede someter su parte de la documentación. Esta se queda
esperando hasta que sea revisada por el coordinador del módulo en cuestión.
El coordinador del módulo relacionado checa si el texto está OK, y lo repasa a el coordinador de la
documentación que lo averigua (posiblemente solamente echando un vistazo) y lo hace público
mediante los mecanismos de Twiki.
El público en general puede acceder a el nuevo texto.
Caso de uso 2 ­ Registro de bugs por parte de los usuarios

13. Figura 3 – Caso de uso 2
Los distintos usuarios del sistema (utilizadores y desarrolladores) necesitan registrarse en el sistema
de gestión de errores.
Cada uno de los módulo de SIGATI (gestión de particiones, gestión de ACLs, gestión de replicas,
gestión de objetos y servicios de red) tiene un responsable que recibe los registros de bugs para su
módulo.
El responsable puede asumir su resolución o atribuirla a otro desarollador de acuerdo con su
necesidad. Eso se hace a través del sistema de manera que los bugs, su estado y su actual responsable
estén siempre listos para consulta por todos los que tienen registro en el sistema.
Perfiles de usuarios
Para el sistema de documentación:
– Perfil de coordinador de la documentación: tiene acceso total al sistema, incluso con privilegios
de cambio en la estructura del wiki y gestión de usuarios del sistema y publicación en definitivo.
– Perfil de coordinador de módulo de SIGATI: tiene acceso normal, pero con privilegios de
aceptación de aportaciones.
– Perfil de usuario del sistema de documentación: accede solamente a las facilidades de edición y
aportación de documentación.
Para el sistema de gestión de errores:

14. – Perfil de coordinador de módulo de SIGATI: los bugs que son para su módulo caen para su
gestión, pero la puede repasar a otro desarollador del módulo.
– Perfil de desarollador: tiene acceso de desarollador con privilegios de aceptación de bugs y
edición de sus evoluciones en el proceso de resolución.
– Perfil de usuario común: accede solamente a las facilidades de edición, visualización y aportación
de bugs.
Plan de pruebas
Antes de la implantación definitiva del sistema, deberán probarse algunos aspectos para minimizar el
riesgo de que aparezcan problemas posteriores:
Para el sistema de documentación:
● Verificar el proceso de registro de usuarios y controle de acceso de los mismos.
● Controle de privilegios de los coordinadores de módulos y lo de documentación (actividades
de revisión y publicación).
● Exportación de los datos de documentación en formato TXT
● Exportación de los datos de documentación en formato HTML
Para el sistema de gestión de errores:
● Verificar el proceso de registro de usuarios y controle de acceso de los mismos.
● Controle de privilegios de los coordinadores de módulos y lo de documentación (actividades
de atribución y revisión).
● Exportación de la base de datos del sistema Bugzilla (Mysql)
Implantación
Planificación de las actividades de integración de sistema – Liberación del
software
1) Preparación del ambiente: instalación de servidores, SO y softwares para los nuevos sistemas

15. (Twiki y Bugzilla): administradores de servidores ­ 1 día
2) Configuración del software de Sistema de Documentación: administradores de servidores,
coordinador de documentación y generadores de documentación (internos de CESMIC) ­ 3
días – depende de 1
3) Configuración del software de Sistema de Gestión de Errores: administradores de servidores,
coordinadores de módulos de SIGATI y usuarios (internos de CESMIC) ­ 3 días – depende de
1
4) Creación de la cuenta de administración del sitio web en “Código Livre”: coordinadores de
módulos de SIGATI ­ ½ día
5) Upload de los paquetes de software preparados y de la documentación ya listos en formato
PDF. Luego la documentación empezará a ser generada y hecha disponible a través del nuevo
sistema de documentación: coordinadores de módulos de SIGATI y coodinador de la
documentación ­ ½ día – depende de 4
6) Creación de la lista de discusión de SIGATI­users en la infraestructura de la UCB:
coordinadores de módulos de SIGATI ­ ½ día
7) Integración de los nuevos servicios con la rutina de backup via ssh de CESMIC:
administradores de servidores ­ ½ día – depende de 2 y 3
8) Creación de la web page inicial del proyecto SIGATI en el WEB server de CESMIC, con los
enlaces adecuados a los sistemas de documentación, gestión de errores y de descarga de
paquetes (site “Código Livre”): administradores de servidores ­ ½ días
9) Importación de la documentación existente para el nuevo sistema de documentación:
administradores de servidores y coordinador de documentación ­ 2 días – depende de 2
10) Pruebas: realizar todas las pruebas especificadas: todos (dependiendo de la prueba en
cuestión) – 10 días – depende de 2 y 3
11) Capacitación: cada uno de los usuarios de CESMIC deberán ser capacitados íntegramente
sobre la forma de llevar a cabo sus tareas en los nuevos sistemas, de manera que cuando
empiecen a utilizar las nuevas herramientas, el cambio no sea improductivo: todos ­ 2 días
12) Mantenimiento: previsto para las soluciones sobre la marcha de cualquier inconveniente que
pueda presentarse en el uso, y para la realización de personalizaciones que no hayan sido
tomadas en cuenta durante la fase de análisis, así como de soporte adicional para los usuarios
del sistema: administradores de servidores – actividad continua.
13) Divulgación el los canales relacionados (listas de correos, web sites, etc) – actividad continua.
Elección de licencias adecuadas
La idea es utilizar la GPL para el software de SIGATI. El software de SIGATI utiliza a los seguientes
softwares:

16. Compilados/Linkados con él:
● API LDAP Novell – licencia OpenLDAP 2.8 (compatible con la GPL)
● STRUTS JAVA – licencia Apache 2.0 (no compatible con la GPL)
● API JAXB – licencia CDDL (Common Development and Distribution License) 1.0 (no
compatible con la GPL)
Utilizados por él (sólo llamadas de programas):
● OpenLDAP ­ licencia OpenLDAP 2.8
Así que SIGATI no podría tener licencia GPL por que no sería compatible con la licencia de STRUTS
(Apache 2.0) y la CDDL 1.0, lo que generaría problemas legales. La licencia elegida para SIGATI
entonces será la de MPL (Mozilla Public License 1.1). Esta licencia lo permite que SIGATI tenga su
licencia MPL mientras STRUTS mantiene su licencia Apache 2.0 y JAXB mantiene su licencia
CDDL1.0. La consecuencia de este hecho es que SIGATI deberá enviar junto con su código, las
obligatorias copias de sus licencias y el fichero LEGAL.txt, donde se pone los avisos legales sobre el
código.
La licencia sobre la documentación wiki generada por el proyecto tendrá licencia GFDL (GNU Free
Documentation License).
Las licencias de los servicios y sistemas siendo implantados (Twiki, Bugzilla, Openssh,
PLONE/ZOPE) son todas de modalidad libre.
Formación
Se deben planificar un mínimo de capacitaciones para la implantación de los nuevos sistemas de
documentación y gestión de errores.
Para los integrantes del lab CESMIC, es posible montar una clase rápida de Twiki y Bugzilla, algo
como un seminario interno. El equipo tiene como que 12 integrantes.
Además, toda la liberación del SIGATI debe ser aclarada para los integrantes de manera que ellos
puedan ayudar a los demás posibles usuarios externos del proyecto. Eso es importante para que la
comunidad que se desea pueda crecer. Nuevos usuarios muchas veces encontran el proyecto por la
WEB, así que es muy importante que el proyecto tenga una buena presentación WEB.
Eso todo se daría en una secuencia de ponencias y pequeñas clases para los integrantes como abajo:
Capacitación Asistentes Duración
El plan de liberación de SIGATI Todos los integrantes de CESMIC ½ día (formato de
seminario)

17. Capacitación Asistentes Duración
El proceso de desarrollo de SIGATI y Todos los integrantes de CESMIC ½ día
las herramientas disponibles
Uso de la herramienta de Coordinadores y generadores de ½ día
documentación (TWiki) documentación
Uso de la herramienta de registro de Usuarios y responsables por módulos ½ día
errores (Bugzilla) de SIGATI
Cabe añadir que la documentación de los sistemas siendo implantados está disponible en la WEB en
los sitios de los mismos. Este material es utilizado para la capacitación en los sistemas.
Mantenimiento
El mantenimiento es una actividad continua a ser planificada a lo largo del proyecto. No se prevé
contractos de soporte por que el equipo asumirá estas actividades en lab CESMIC. Esta es una de las
ventajas de se utilizar software libre. Aunque se podría contactar a una empresa de servicios, el lab
asumirá el mantenimiento por que ya tiene conocimiento de los sistemas elegidos para el proyecto.
Para que no haya sorpresas en los nuevos sistemas, la implantación mantendrá responsables por cada
sistema en modalidad de guardia en la parte inicial de implantación.