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.