Proyecto liberació SIGATI
Upcoming SlideShare
Loading in...5
×
 

Proyecto liberació SIGATI

on

  • 692 views

Projeto de conclusão de curso de "Posgrado en Gestión de Sistemas de Información en Entornos de Software Libre" - Barcelona 2006

Projeto de conclusão de curso de "Posgrado en Gestión de Sistemas de Información en Entornos de Software Libre" - Barcelona 2006

Statistics

Views

Total Views
692
Views on SlideShare
692
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    Proyecto liberació SIGATI Proyecto liberació SIGATI Document Transcript

    • PEC3 – Proyecto de Gestión de Sistemas de Información en  Entornos de Software Libre Mauro Tapajós SantosLiberació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ónEstudiar 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 ViabilidadNecesidades 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ón1) 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 SoftwareSobre 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 SistemaDefinició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)– Bugzilladentro 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 SIGATIDefinición de estándares y normasPara 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 usuariosPara 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 montadosEstablecimiento de requisitosRequisitos 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 usoCaso de uso 1 ­ Aporte de documentación por parte de usuarios
    • Figura 2 – Caso de uso 1Cada 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 2Los 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 usuariosPara 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 pruebasAntes 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 HTMLPara 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ónPlanificació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 adecuadasLa 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.8Así 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  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 SIGATICabe 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.MantenimientoEl 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.