SlideShare una empresa de Scribd logo
1 de 17
Descargar para leer sin conexión
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 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).
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ó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)
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.

Más contenido relacionado

Destacado

CCNA - Introdução a redes para certificação 640-802 // CISCO
CCNA - Introdução a redes para certificação 640-802 // CISCOCCNA - Introdução a redes para certificação 640-802 // CISCO
CCNA - Introdução a redes para certificação 640-802 // CISCODinei Vicente
 
Packet Tracer
Packet TracerPacket Tracer
Packet Tracerdanists
 
Redes Avançadas - 3.Noções de Projeto de Redes
Redes Avançadas - 3.Noções de Projeto de RedesRedes Avançadas - 3.Noções de Projeto de Redes
Redes Avançadas - 3.Noções de Projeto de RedesMauro Tapajós
 
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet Tracer
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet TracerCriando rede WLAN e SERVIDOR DNS E HTTP no Packet Tracer
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet TracerEdenilton Michael
 
Laboratorio packet tracer dhcp-dns-http
Laboratorio packet tracer dhcp-dns-httpLaboratorio packet tracer dhcp-dns-http
Laboratorio packet tracer dhcp-dns-httphhlezana
 
Redes I - 1.Introdução às Redes de Comunicação de Dados
Redes I - 1.Introdução às Redes de Comunicação de DadosRedes I - 1.Introdução às Redes de Comunicação de Dados
Redes I - 1.Introdução às Redes de Comunicação de DadosMauro Tapajós
 
Tutorial packet-tracer
Tutorial packet-tracerTutorial packet-tracer
Tutorial packet-tracerdharla quispe
 
Criação e Desenvolvimento de Personagens
Criação e Desenvolvimento de PersonagensCriação e Desenvolvimento de Personagens
Criação e Desenvolvimento de PersonagensSabrina Carmona
 
Livro Programação em Shell 8 edição Julio Cézar Nevez
Livro Programação em Shell 8 edição   Julio Cézar NevezLivro Programação em Shell 8 edição   Julio Cézar Nevez
Livro Programação em Shell 8 edição Julio Cézar NevezSoftD Abreu
 
Técnicas hacker soluções para segurança 1
Técnicas hacker soluções para segurança 1Técnicas hacker soluções para segurança 1
Técnicas hacker soluções para segurança 1ponto hacker
 
Redes e Servidores Linux - Guia Prático - Carlos E. Morimoto
Redes e Servidores Linux - Guia Prático - Carlos E. MorimotoRedes e Servidores Linux - Guia Prático - Carlos E. Morimoto
Redes e Servidores Linux - Guia Prático - Carlos E. MorimotoHeber Gutenberg
 
Livro curso de_hacker_para_iniciantes_cap_1
Livro curso de_hacker_para_iniciantes_cap_1Livro curso de_hacker_para_iniciantes_cap_1
Livro curso de_hacker_para_iniciantes_cap_1Alax Ricard
 
14 06-09 mae-informe-diario
14 06-09 mae-informe-diario14 06-09 mae-informe-diario
14 06-09 mae-informe-diarioPablo Simoes
 

Destacado (20)

CCNA - Introdução a redes para certificação 640-802 // CISCO
CCNA - Introdução a redes para certificação 640-802 // CISCOCCNA - Introdução a redes para certificação 640-802 // CISCO
CCNA - Introdução a redes para certificação 640-802 // CISCO
 
Packet Tracer
Packet TracerPacket Tracer
Packet Tracer
 
Redes Avançadas - 3.Noções de Projeto de Redes
Redes Avançadas - 3.Noções de Projeto de RedesRedes Avançadas - 3.Noções de Projeto de Redes
Redes Avançadas - 3.Noções de Projeto de Redes
 
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet Tracer
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet TracerCriando rede WLAN e SERVIDOR DNS E HTTP no Packet Tracer
Criando rede WLAN e SERVIDOR DNS E HTTP no Packet Tracer
 
Sistemas Operacionais
Sistemas OperacionaisSistemas Operacionais
Sistemas Operacionais
 
Laboratorio packet tracer dhcp-dns-http
Laboratorio packet tracer dhcp-dns-httpLaboratorio packet tracer dhcp-dns-http
Laboratorio packet tracer dhcp-dns-http
 
Apostila Redes
Apostila RedesApostila Redes
Apostila Redes
 
Redes I - 1.Introdução às Redes de Comunicação de Dados
Redes I - 1.Introdução às Redes de Comunicação de DadosRedes I - 1.Introdução às Redes de Comunicação de Dados
Redes I - 1.Introdução às Redes de Comunicação de Dados
 
Tutorial packet-tracer
Tutorial packet-tracerTutorial packet-tracer
Tutorial packet-tracer
 
Criação e Desenvolvimento de Personagens
Criação e Desenvolvimento de PersonagensCriação e Desenvolvimento de Personagens
Criação e Desenvolvimento de Personagens
 
Livro Programação em Shell 8 edição Julio Cézar Nevez
Livro Programação em Shell 8 edição   Julio Cézar NevezLivro Programação em Shell 8 edição   Julio Cézar Nevez
Livro Programação em Shell 8 edição Julio Cézar Nevez
 
Apostila Jogos
Apostila Jogos Apostila Jogos
Apostila Jogos
 
Técnicas hacker soluções para segurança 1
Técnicas hacker soluções para segurança 1Técnicas hacker soluções para segurança 1
Técnicas hacker soluções para segurança 1
 
Redes e Servidores Linux - Guia Prático - Carlos E. Morimoto
Redes e Servidores Linux - Guia Prático - Carlos E. MorimotoRedes e Servidores Linux - Guia Prático - Carlos E. Morimoto
Redes e Servidores Linux - Guia Prático - Carlos E. Morimoto
 
Livro curso de_hacker_para_iniciantes_cap_1
Livro curso de_hacker_para_iniciantes_cap_1Livro curso de_hacker_para_iniciantes_cap_1
Livro curso de_hacker_para_iniciantes_cap_1
 
El equipo de gmail mail
El equipo de gmail mailEl equipo de gmail mail
El equipo de gmail mail
 
Dizjornal127
Dizjornal127Dizjornal127
Dizjornal127
 
Diz Jornal - Edição 164
Diz Jornal - Edição 164Diz Jornal - Edição 164
Diz Jornal - Edição 164
 
César borges 1999 2002
César borges 1999 2002César borges 1999 2002
César borges 1999 2002
 
14 06-09 mae-informe-diario
14 06-09 mae-informe-diario14 06-09 mae-informe-diario
14 06-09 mae-informe-diario
 

Similar a Proyecto liberació SIGATI

decreto presidencial
decreto presidencialdecreto presidencial
decreto presidencialsantiagazomua
 
Trabajo normas apa sistemas operativos
Trabajo normas apa  sistemas operativosTrabajo normas apa  sistemas operativos
Trabajo normas apa sistemas operativosAlonsoCelyPacheco
 
decreto presidencial
decreto presidencialdecreto presidencial
decreto presidencialchelitafur
 
Propuesta del proyecto
Propuesta del proyectoPropuesta del proyecto
Propuesta del proyectodamesaa
 
Anexo 28-actividad-7
Anexo 28-actividad-7Anexo 28-actividad-7
Anexo 28-actividad-7Draven Draven
 
Jacqueline analuisa
Jacqueline analuisa Jacqueline analuisa
Jacqueline analuisa yacque-1992
 
Jacqueline analuisa nivel propedeútico
Jacqueline analuisa nivel propedeúticoJacqueline analuisa nivel propedeútico
Jacqueline analuisa nivel propedeúticoyacque-1992
 
Normas apa monica. .pacheco
Normas apa monica. .pachecoNormas apa monica. .pacheco
Normas apa monica. .pachecoMonicaPacheco29
 
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...Danny Salazar Noboa
 

Similar a Proyecto liberació SIGATI (20)

Elementary 2
Elementary 2Elementary 2
Elementary 2
 
decreto presidencial
decreto presidencialdecreto presidencial
decreto presidencial
 
Komputazion
KomputazionKomputazion
Komputazion
 
Trabajo normas apa sistemas operativos
Trabajo normas apa  sistemas operativosTrabajo normas apa  sistemas operativos
Trabajo normas apa sistemas operativos
 
decreto presidencial
decreto presidencialdecreto presidencial
decreto presidencial
 
Komputazion
KomputazionKomputazion
Komputazion
 
decreto presindencial
decreto presindencialdecreto presindencial
decreto presindencial
 
Komputazion
KomputazionKomputazion
Komputazion
 
decreto presidencial
decreto presidencialdecreto presidencial
decreto presidencial
 
Compu
CompuCompu
Compu
 
Decreto
DecretoDecreto
Decreto
 
Propuesta del proyecto
Propuesta del proyectoPropuesta del proyecto
Propuesta del proyecto
 
Anexo 28-actividad-7
Anexo 28-actividad-7Anexo 28-actividad-7
Anexo 28-actividad-7
 
Ing. de software
Ing. de softwareIng. de software
Ing. de software
 
Jacqueline analuisa
Jacqueline analuisa Jacqueline analuisa
Jacqueline analuisa
 
Jacqueline analuisa nivel propedeútico
Jacqueline analuisa nivel propedeúticoJacqueline analuisa nivel propedeútico
Jacqueline analuisa nivel propedeútico
 
Compu deber
Compu deberCompu deber
Compu deber
 
Normas apa monica. .pacheco
Normas apa monica. .pachecoNormas apa monica. .pacheco
Normas apa monica. .pacheco
 
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...
Protocolo de Red LAN entre distintos sistemas operativos. (DANNY SALAZAR ;FAB...
 
Compu 2
Compu 2Compu 2
Compu 2
 

Más de Mauro Tapajós

Propostas de Autenticação para SNMP
Propostas de Autenticação para SNMPPropostas de Autenticação para SNMP
Propostas de Autenticação para SNMPMauro Tapajós
 
Integração de Serviços em Plataforma Livre
Integração de Serviços em Plataforma LivreIntegração de Serviços em Plataforma Livre
Integração de Serviços em Plataforma LivreMauro Tapajós
 
Instalação e Atualização Automática de Aplicações para Ambientes Corporativos
Instalação e Atualização Automática de Aplicações para Ambientes CorporativosInstalação e Atualização Automática de Aplicações para Ambientes Corporativos
Instalação e Atualização Automática de Aplicações para Ambientes CorporativosMauro Tapajós
 
Serviço de Distribuição de SW em Plataforma Livre
Serviço de Distribuição de SW em Plataforma LivreServiço de Distribuição de SW em Plataforma Livre
Serviço de Distribuição de SW em Plataforma LivreMauro Tapajós
 
Migração para Software Livre nas Universidades
Migração para Software Livre nas UniversidadesMigração para Software Livre nas Universidades
Migração para Software Livre nas UniversidadesMauro Tapajós
 
Códigos Convolucionais (sequenciais)
Códigos Convolucionais (sequenciais)Códigos Convolucionais (sequenciais)
Códigos Convolucionais (sequenciais)Mauro Tapajós
 
Posso rodar minhas aplicações corporativas sobre linux?
Posso rodar minhas aplicações corporativas sobre linux?Posso rodar minhas aplicações corporativas sobre linux?
Posso rodar minhas aplicações corporativas sobre linux?Mauro Tapajós
 
integração de Serviços no Processo de Migração para uma Plataforma Livre
integração de Serviços no Processo de Migração para uma Plataforma Livreintegração de Serviços no Processo de Migração para uma Plataforma Livre
integração de Serviços no Processo de Migração para uma Plataforma LivreMauro Tapajós
 
Atualização Automática de Aplicações em plataforma livre
Atualização Automática de Aplicações em plataforma livreAtualização Automática de Aplicações em plataforma livre
Atualização Automática de Aplicações em plataforma livreMauro Tapajós
 
Integração de Serviços como requisito fundamental no processo de migração par...
Integração de Serviços como requisito fundamental no processo de migração par...Integração de Serviços como requisito fundamental no processo de migração par...
Integração de Serviços como requisito fundamental no processo de migração par...Mauro Tapajós
 
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...Mauro Tapajós
 
Processo de Startup do Linux
Processo de Startup do LinuxProcesso de Startup do Linux
Processo de Startup do LinuxMauro Tapajós
 
Aspectos do kernel Linux e Instalação
Aspectos do kernel Linux e InstalaçãoAspectos do kernel Linux e Instalação
Aspectos do kernel Linux e InstalaçãoMauro Tapajós
 
Avaliação das distribuições Linux
Avaliação das distribuições LinuxAvaliação das distribuições Linux
Avaliação das distribuições LinuxMauro Tapajós
 
FISL8 - Aplicações Livres para Gerenciamento de Redes e Serviços
FISL8 - Aplicações Livres para Gerenciamento de Redes e ServiçosFISL8 - Aplicações Livres para Gerenciamento de Redes e Serviços
FISL8 - Aplicações Livres para Gerenciamento de Redes e ServiçosMauro Tapajós
 
FISL7 - Padrões Abertos e Software Livre para Vídeoconferência
FISL7 - Padrões Abertos e Software Livre para VídeoconferênciaFISL7 - Padrões Abertos e Software Livre para Vídeoconferência
FISL7 - Padrões Abertos e Software Livre para VídeoconferênciaMauro Tapajós
 
Suporte e Disponibilidade no Linux
Suporte e Disponibilidade no LinuxSuporte e Disponibilidade no Linux
Suporte e Disponibilidade no LinuxMauro Tapajós
 
Pequena Apostila sobre Software Livre
Pequena Apostila sobre Software LivrePequena Apostila sobre Software Livre
Pequena Apostila sobre Software LivreMauro Tapajós
 

Más de Mauro Tapajós (20)

Propostas de Autenticação para SNMP
Propostas de Autenticação para SNMPPropostas de Autenticação para SNMP
Propostas de Autenticação para SNMP
 
Integração de Serviços em Plataforma Livre
Integração de Serviços em Plataforma LivreIntegração de Serviços em Plataforma Livre
Integração de Serviços em Plataforma Livre
 
Instalação e Atualização Automática de Aplicações para Ambientes Corporativos
Instalação e Atualização Automática de Aplicações para Ambientes CorporativosInstalação e Atualização Automática de Aplicações para Ambientes Corporativos
Instalação e Atualização Automática de Aplicações para Ambientes Corporativos
 
Asterisk
AsteriskAsterisk
Asterisk
 
Serviço de Distribuição de SW em Plataforma Livre
Serviço de Distribuição de SW em Plataforma LivreServiço de Distribuição de SW em Plataforma Livre
Serviço de Distribuição de SW em Plataforma Livre
 
Migração para Software Livre nas Universidades
Migração para Software Livre nas UniversidadesMigração para Software Livre nas Universidades
Migração para Software Livre nas Universidades
 
Códigos Convolucionais (sequenciais)
Códigos Convolucionais (sequenciais)Códigos Convolucionais (sequenciais)
Códigos Convolucionais (sequenciais)
 
Posso rodar minhas aplicações corporativas sobre linux?
Posso rodar minhas aplicações corporativas sobre linux?Posso rodar minhas aplicações corporativas sobre linux?
Posso rodar minhas aplicações corporativas sobre linux?
 
Software Winrad
Software WinradSoftware Winrad
Software Winrad
 
integração de Serviços no Processo de Migração para uma Plataforma Livre
integração de Serviços no Processo de Migração para uma Plataforma Livreintegração de Serviços no Processo de Migração para uma Plataforma Livre
integração de Serviços no Processo de Migração para uma Plataforma Livre
 
Atualização Automática de Aplicações em plataforma livre
Atualização Automática de Aplicações em plataforma livreAtualização Automática de Aplicações em plataforma livre
Atualização Automática de Aplicações em plataforma livre
 
Integração de Serviços como requisito fundamental no processo de migração par...
Integração de Serviços como requisito fundamental no processo de migração par...Integração de Serviços como requisito fundamental no processo de migração par...
Integração de Serviços como requisito fundamental no processo de migração par...
 
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...
Instalação e Atualização Automática de Aplicações em Plataforma Livre para Am...
 
Processo de Startup do Linux
Processo de Startup do LinuxProcesso de Startup do Linux
Processo de Startup do Linux
 
Aspectos do kernel Linux e Instalação
Aspectos do kernel Linux e InstalaçãoAspectos do kernel Linux e Instalação
Aspectos do kernel Linux e Instalação
 
Avaliação das distribuições Linux
Avaliação das distribuições LinuxAvaliação das distribuições Linux
Avaliação das distribuições Linux
 
FISL8 - Aplicações Livres para Gerenciamento de Redes e Serviços
FISL8 - Aplicações Livres para Gerenciamento de Redes e ServiçosFISL8 - Aplicações Livres para Gerenciamento de Redes e Serviços
FISL8 - Aplicações Livres para Gerenciamento de Redes e Serviços
 
FISL7 - Padrões Abertos e Software Livre para Vídeoconferência
FISL7 - Padrões Abertos e Software Livre para VídeoconferênciaFISL7 - Padrões Abertos e Software Livre para Vídeoconferência
FISL7 - Padrões Abertos e Software Livre para Vídeoconferência
 
Suporte e Disponibilidade no Linux
Suporte e Disponibilidade no LinuxSuporte e Disponibilidade no Linux
Suporte e Disponibilidade no Linux
 
Pequena Apostila sobre Software Livre
Pequena Apostila sobre Software LivrePequena Apostila sobre Software Livre
Pequena Apostila sobre Software Livre
 

Proyecto liberació SIGATI

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