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, 

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.

• 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).

• 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

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 

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 

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 softwareDespué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).

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.

• 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.

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).

• 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

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

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:

– 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 

(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:

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ónSe 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)

Capacitación Asistentes Duración

El proceso de desarrollo de SIGATI y las herramientas disponibles

Todos los integrantes de CESMIC ½ día

Uso de la herramienta de documentación (TWiki)

Coordinadores y generadores de documentación

½ día

Uso de la herramienta de registro de errores (Bugzilla)

Usuarios y responsables por módulos de SIGATI

½ día

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.