Herramientas Personales
gvSIG Desktop
gvSIG Desktop

Cached time 11/21/13 07:54:14 Clear cache and reload

 
Acciones de Documento

Proyectos oficiales en gvSIG

por Joaquin Jose del Cerro MurcianoÚltima modificación 26/01/2011 15:42
Version: 1.12

Alcance

Este documento cubre los requerimientos que debe cumplir un desarrollo para pasar a ser un proyecto oficial de gvSIG.

Exclusiones

Este documento no cubre:

  • Qué debe cumplir un proyecto para que se incluya en la distribución oficial de la aplicación gvSIG.

    Para que se incluya en la distribución oficial de gvSIG deberá ser un proyecto oficial gvSIG, pero que cumpla este requerimiento no lo garantiza de forma automática.

  • Modificaciones o contribuciones a código ya existente en gvSIG.

    Si desea aportar código a un proyecto ya existente en gvSIG consulte el documento Contribuciones y parches al código de gvSIG.

Niveles de oficialidad de contribuciones de desarrollo en gvSIG

Antes de ver estos requerimientos, hay que concretar que existen dos niveles de oficialidad que puede tener un desarrollo:

  • Nivel básico. Se integra el testeo, documentación de usuario pero el proyecto gvSIG no se hace cargo de mantenerlo, corrección de bugs, añadir nuevas funcionalidades o adaptarlo a una nueva versión.

    Si se decide incluir en una distribución oficial y para una nueva versión no compila o falla en tiempo de ejecución o hace que otra extensión falle, simplemente se comunicará al contribuidor que aporta la extensión y si no dedica recursos a ello se retirará de la versión.

    Este nivel apenas cubre restricciones de empaquetado, documentación, y testing de usuario, no exigiendo que se cumplan ninguna de las normas o recomendaciones respecto a diseño e implementación, con lo que mantener el desarrollo para los miembros que estén trabajando con gvSIG puede tener un coste bastante elevado.

  • Nivel completo. La contribución se integra tanto a nivel de testeo y documentación de usuario como de desarrollo. El proyecto gvSIG podrá hacerse cargo de la corrección de algún bug y la adaptación a las nuevas versiones que vayan surgiendo, todo ello en función de los recursos que tenga el proyecto en ese momento.

La principal diferencia de un nivel a otro estriba en que el uno fija requerimientos relacionados con el empaquetado y distribución de un proyecto, mientras que el otro entra ya en temas relacionados con el desarrollo (análisis, diseño, codificación, documentación para desarrolladores,...)

Requerimientos para un desarrollo oficial de gvSIG

Los requerimientos que fija cada nivel deben interpretarse como acumulativos, siempre que no se diga lo contrario en lo que a algún requerimiento se refiere. Esto quiere decir que para estar en el nivel completo debe cumplir los del nivel básico.

De los requerimientos a cubrir por un proyecto para pasar a ser un proyecto oficial de gvSIG, algunos deberán cubrirse al inicio del proceso de validación o certificación mientras que otros podrán irse cubriendo a lo largo del proceso.

Nivel básico

Requerimientos al inicio del proceso de certificación:

  • Deberá suministrarse una persona de contacto con capacidad para toma de decisiones en todo lo referente al desarrollo.

  • La licencia del desarrollo debe ser compatible GPL v2 o posterior y no debe usar ninguna otra librería que sea incompatible con esta licencia.

    En cuanto a la documentación entregada junto con el proyecto para conseguir el reconocimiento de proyecto oficial, deberá usarse una licencia compatible GPL v2 o posterior o una licencia Creative Commons que permita el uso comercial de esta asi como su modificación manteniendo las mismas restricciones de redistribución que la documentación original.

  • Deberá entregarse un informe de dependencias de la librería o extensión, en el que se indique de qué librerías depende y su versión. Este informe debe contemplar las dependencias con otras extensiones y librerías de gvSIG, estando estas dependencias bien identificadas.

    Así mismo también se indicarán las dependencias con librerías nativas.

    Este documento deberá mantenerse actualizado a lo largo de la vida del proyecto.

    Si el proyecto usa maven como mecanismo de construcción bastará con entregar el informe de dependencias del sitio maven generado con mvn site. En caso de no usar maven se utilizará la plantilla Project Dependencies.

  • Deberá existir una forma inequívoca de identificar una revisión del desarrollo. Normalmente si es una librería deberá llevar un número de versión en el nombre del jar, y si es una extensión un número de build único para esa extensión. No deberán existir dos binarios distintos con el mismo nombre y número de versión.

  • Los fuentes a partir de los que se generen los binarios y las herramientas necesarias para generarlos deberán estar de acceso público

    Actualmente gvSIG está usando la forja de OSOR como espacio para el proyecto en el que se incluye un repositorio de SVN de acceso público en modo lectura, trackers para errores y tareas, etc. Si el proyecto no dispone de infraestructura para su gestión, gvSIG puede coordinar la creación de un nuevo proyecto para el colaborador.

  • Cuando se descarguen los fuentes desde el repositorio de fuentes deberá existir en el raíz del proyecto un fichero README.txt que describa qué hay que hacer para compilar, desplegar y generar el instalable.

Los requerimientos a cubrir a lo largo del proceso de certificación son:

  • Deberá existir una documentación de análisis que describa el desarrollo.

    No es preciso llegar a nivel de diseño, pero sí es imprescindible que esté a nivel de análisis. Grandes módulos y relación de estos con otros módulos de gvSIG.

  • Deberá suministrarse una forma repetible y documentada de generar instalables para la extensión en gvSIG. Se preferirá que se use el procedimiento al uso para la versión corriente de gvSIG para empaquetar las extensiones.

  • Deberá ser internacionalizable usando las librerías de gvSIG para ello. Se entregará como mínimo en inglés.

  • Deberá de entregarse un manual de usuario, en formato ReST y según las normas de redacción de documentación vigentes en gvSIG (Guía para documentar). La documentación de usuarios a entregar deberá cubrir:

    • Documentación de uso.
    • Documentación de instalación.
    • Créditos que deben incluirse en el manual de gvSIG cuando se incluya la documentación asociada a este proyecto.
  • Debera suministrarse un instalable del proyecto.

    Si es un plugin para gvSIG se recomienda usar las reglas de nombrado para este o en su lugar suministrar unas claras que seran evaluadas por el equipo de gvSIG.

    Este instalable se encargara de instalar la extension sobre un gvSIG, y debera suministrar un fichero con los metadatos del plugin siguiendo el formato inficado en la plantilla para estos (package.info (Template)).

  • En lo que a testing se refiere los requerimientos serian:

    1. Deberá diseñarse un Plan de Pruebas (PDP) que cubra por entero las nuevas funcionalidades, como mínimo hasta el nivel de caso de prueba. Se tendrán en cuenta tanto las pruebas funcionales como las de persistencia. El PDP se introducirá en la aplicación de gestión de Planes de Prueba del proyecto y se realizará una primera ejecución desde la misma. Podrá solicitarse también la ejecución de una campaña de pruebas, que el Área de Testing diseñará ex-profeso, en función del análisis del impacto de los nuevos desarrollos sobre el resto de la aplicación, incluyendo pruebas de regresión y de persistencia. Recomendablemente se dará de alta un boletín de bug por cada error encontrado al ejecutar las pruebas, indicando el paso concreto en el que se ha detectado el error.

    2. Se abordará una fase de estabilización en la que un equipo de desarrolladores y otro de testers trabajarán de manera intensiva y coordinada en la corrección de errores, tanto en los propios de las nuevas funcionalidades como en los que haya provocado la integración de éstas en el resto de la aplicación.

    3. Cuando para una versión de gvSIG el desarrollo no pase el plan de pruebas este perderá la denominación de proyecto oficial para esa versión de gvSIG.

    4. Deberá existir un gestor de bugs y nuevas funcionalidades de acceso publico, permitiendo a usuarios anónimos que puedan dar de alta tickets en él.

      En caso de que no se disponga de uno se podría usar la forma de OSOR, para albergar los fuentes, descargas de binarios y gestión de tickets para ese proyecto, y en última instancia se podrían incluir en el gestor de bugs de la aplicación gvSIG.

    Ver esquema general de procedimientos de testing

  • Deberá haber un plugin de gvSIG por funcionalidad o grupo de funcionalidades relacionadas desde el punto de vista del usuario, habiendo un proyecto de eclipse para cada uno de los plugins.

  • Deberá existir una política clara y conocida en relación al mantenimiento del número de versión del proyecto.

  • Deberá existir una política clara y conocida en relación al nombrado de los ficheros de la distribución del proyecto.

  • La instalación de un plugin en gvSIG no deberá sobre escribir ninguna de las librerías que se incluyan con la distribución oficial de gvSIG.

Existen dos plantillas en formato ReST que deberán ser rellenadas y entregadas con los datos básicos del proyecto, la ficha del proyecto y los contactos del proyecto.

Nivel completo

Este nivel sólo aporta requerimientos a cubrir al final del proceso de certificación.

  • Se utilizara maven como entorno de construcción de la extensión o librería, utilizando la estructura de proyecto para gvSIG. Con los criterios de nombrado de paquetes, artefactos y librerías de gvSIG.

    Asi mismo deberan estar correctamente cumplimentados los ficheros pom.xml incluyendo por ejemplo:

    • Descripción del proyecto.
    • Enlaces a repositorio de código.
    • Enlaces a listas de correo.
    • Desarrolladores.
    • Etc.
  • Existirá una documentación completa del API a través de los javadocs, y un mecanismo que permita desplegarlos en el sitio donde residan éstos en el proyecto gvSIG. La documentación del API se redactará en inglés.

  • Deberán existir pruebas automatizadas, usando tests JUnit que cubran el API de la extensión o librería.

  • Habrá una separación estricta entre la lógica y la parte de interface de usuario.

  • Habrá una separación estricta entre API e implementación, generándose una librería para el API separada de la implementación. Tanto para la lógica como para el interface de usuario.

  • Deberá seguir las normas de codificación vigentes en el proyecto.

  • Deberá confeccionarse una guía para el desarrollador que documente cómo usar las funcionalidades. El idioma en el que se confeccione esta guía será preferentemente el inglés.

  • La documentación de desarrollo que se genere deberá estar en formato ReST.

Como iniciar los tramites

Si está interesado en que su desarrollo sea un proyecto oficial de gvSIG puede solicitarlo dando de alta un ticket o boletin en la página habilitada para solicitudes de proyectos oficiales en la forja de OSOR.

Describa en unos pocos párrafos la funcionalidad que aporta su desarrollo en el ticket aportando como documentos adjuntos las plantillas de ficha del proyecto y contactos del proyecto. Para rellenar las plantillas recuerde hacerlo a partir del código fuente de estas. Puede encontrar más informacion sobre cómo acceder a los fuentes de un documento aquí.

A partir de esto se pondrá en contacto con usted la persona adecuada del proyecto gvSIG para llevar la coordinación de las tareas de oficializar su desarrollo en gvSIG.

Registro de cambios
versión Descripción
1.1 Añadido enlace a una plantilla para el informe de dependencias.
1.2 Sustituido el enlace a la plantilla del informe de dependencias por enlace a un documento que describe como rellenar la plantilla del informe de dependencias y de donde obtenerla.
1.2 Añadido enlace a un documento explicativo de como rellenar el README.txt a incluir con los fuentes y donde obtener la plantilla de este.
1.2 Añadido enlace a un documento explicativo de que debe entregarse como documentación de análisis para el nivel básico, así como enlace a un ejemplo.
1.2 Añadido enlaces a las plantilla de la ficha del proyecto y los contactos
1.2 Corregida referencia a nivel basico y avanzado. En un punto se referenciaban como minimo y alto.
1.3 Rehecho el primer párrafo del documento para que exprese mejor lo que es un proyecto oficial de gvSIG.
1.4 Añadido requerimiento de que funcionalidades distintas van en plugins distintos.
1.5 Añadido requerimiento de política relacionada con la versión.
1.5 Añadido requerimiento de política relacionada con el nombrado de ficheros de una distribución.
1.5 Sustituido el requerimiento de seguir las normas de nombrado de clases por el de seguir las normas de codificación.
1.6 Añadido el epígrafe "Como iniciar los tramites".
1.6 Correcciones ortográficas y de sintaxis.
1.7 Subdividida la sección alcance en dos, alcance y exclusiones. y añadido enlace a Contribuciones y parches al código de gvSIG
1.8 No se deben sobre escribir librerías de gvSIG.
1.9 Añadidas condiciones sobre la licencia de la documentacion entregada.
1.10 Añadidas la nota de que si no pasa el plan de pruebas en una version pierde la enominacion de proyecto oficial (punto 3 de requerimientos de testing).
1.10 Añadido que se requiere un gestor de bugs publico para el proyecto (punto 4 de requerimientos de testing).
1.10 Extendidas la descripcion de que documentacion de usuario debe entregarse, manual de uso, de instalacion y derechos.
1.11 Añadido parrafo sobre que el fichero pom.xml debe estar correctamente cumplimentado.
1.12 Añadido requerimiento sobre el instalable a entregar para elproyecto o plugin.

Hecho con Plone CMS, el Sistema de Gestión de Contenidos de Fuentes Abiertos

Este sitio cumple con los siguientes estándares: