El objetivo de este proceso es la creación de los componentes del código fuente desarrollado por los programadores, tanto para los componentes de un proyecto FundeWeb (paginas HTML-XHTML, CSS, Javascript, Java, informes Birt, etc.) como los artefactos de la base de datos (Script de tablas; procedimientos, funciones y paquetes PL/SQL, script de vistas, etc.). Este proceso, es la primera parte de cada iteración que se realiza en la metodología de desarrollo.

Debe de existir previamente, un JIRA indicando que se va a crear o modificar un componente. El desarrollador, debe indicar en dicho JIRA que se va a trabajar en dicha tarea iniciando su proceso mediante el botón Iniciar Progreso que tienen todas las tareas de JIRA.

También tenemos que tener actualizado el proyecto a la ultima revisión del SVN, para minimizar los posibles conflictos de código.

Antes de empezar a realizar esta tarea, es recomendable tener actualizado el proyecto relativo a la rama del SVN con la que vamos a trabajar (ya sea un branch o el trunk).

Este es el proceso basico de desarrollo de software. Podemos crear o modificar principalmente dos tipos de componentes: los artefactos de la aplicación (clases Java, Paginas XHTML o HTML, ficheros Javascript, CSS, informes Birt, etc.) y los artefactos de la base de datos (Script de definición de tablas, configuración de segments y tablespaces, triggers, funciones, procedimientos y paquetes PL/SQL).

Para realizar esta tarea tendremos que seguir algunas normativas de desarrollo, por ejemplo:

- Para aplicaciones FundeWeb, seguiremos la Normativa de Desarrollo de Aplicaciones FundeWeb (también podemos consultar la antigua Normativa de Desarrollo con FundeWEB v1.0.

- Para artefactos de la Base de Datos, seguiremos la Normativa de Desarrollo de Artefactos de Base de Datos, y crearemos el modelo físico de datos, a partir del modelo lógico, usando también Oracle Data Modeler.

Cada día de trabajo, el desarrollador debe de indicar las horas trabajadas en la tarea.

Lo puede hacer desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Más Acciones –> Registrar Horas de Trabajo y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

O bien se puede hacer con el plugin de JIRA para el Eclipse.

En ambos casos tendremos que rellenar la siguiente información.

Para almacenar la información en JIRA utilizaremos el botón Registrar.

Debe de existir previamente, un JIRA indicando que se va a crear o modificar un test unitario. El desarrollador, debe indicar en dicho JIRA que se va a trabajar en dicha tarea iniciando su proceso mediante el botón Iniciar Progreso que tienen todas las tareas de JIRA.

También tenemos que tener actualizado el proyecto a la ultima revisión del SVN, para minimizar los posibles conflictos de código.

Se creara un test unitario cuando el componente no tenga ningún test unitario. Se modificara un test unitario, cuando exista previamente y haya que modificarlo para soportar la modificación del componente asociado al test.

Podemos crear o modificar test unitarios para los siguientes componentes: los artefactos de la aplicación (clases Java) y los artefactos de la base de datos (triggers, funciones, procedimientos y paquetes PL/SQL).

Hay que realizar una pila de test unitarios por cada componente y además se deben añadir test unitarios para comprobar los errores controlados de la aplicación se lanzan correctamente. Para las aplicaciones FundeWeb, los test unitarios se realizan a nivel de método de la clase. Para los artefactos de base de datos se realizan a nivel de llamada.

Para realizar esta tarea tendremos que seguir algunas normativas de desarrollo, por ejemplo:

• Para aplicaciones FundeWeb, seguiremos la Guía Técnica de Test Unitarios que se indica en la Normativa de Desarrollo de Aplicaciones FundeWeb v1.0. También puedes consultar la Normativa de Desarrollo de Aplicaciones FundeWeb v2.0.
• Para artefactos de la Base de Datos, seguiremos la Normativa de Desarrollo de Artefactos de Base de Datos.

Para aceptar a una pila test unitarios de un componente, todas los test unitarios tienen que ser satisfactorios. Hay que realizar test que comprueben también los errores. Los test se ejecutaran en las siguientes herramientas:

• En el IDE Eclipse mediante el plugin TestNG para aplicaciones FundeWeb.
• En el TOAD para test de los artefactos de Base de Datos.

Cada día de trabajo, el desarrollador debe de indicar las horas trabajadas en la tarea.

Lo puede hacer desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Más Acciones –> Registrar Horas de Trabajo y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

Tendremos que rellenar la siguiente información.

Para almacenar la información, en JIRA, utilizaremos el botón Registrar.

Para finalizar el proceso, tenemos que subir al servidor de control de versiones los componentes creados o modificados y los test unitarios asociados a estos. Dependiendo del tipo de artefacto utilizaremos una herramienta u otra para subir al repositorio SVN:

- Aplicaciones FundeWeb: se puede utilizar tanto el IDE Eclipse con su plugin subeclipse como Tortoise SVN.

- Artefactos de la Base de Datos: utilizaremos Oracle SQL Developer o Tortoise SVN, siguiendo las indicaciones de la Normativa de Control de Versiones de Código PL/SQL.

IMPORTANTE: al subir un cambio al repositorio SVN tenemos que rellenar el “mensaje de log” que nos pide el servidor SVN, incluyendo el código del jira correspondiente al trabajo que estamos haciendo, da igual q pongamos el código del jira al inicio, medio o final del comentario. Podemos indicar varios códigos de jiras distintos en el mismo comentario. De ese modo podremos ver lo que hemos subido al servidor SVN en la pestaña Subversion del jira correspondiente.

Una vez subidos los componentes y los artefactos al repositorio SVN, podemos resolver los JIRAs asociados a las tareas de Crear o Modificar Componente y a Crear y Ejecutar Test Unitarios de los Componentes.

Para resolver un JIRA, podemos hacerlo desde JIRA, vamos a la tarea, y en el menú asociado a esta pinchamos en, Resolver Incidencia y en la pantalla que aparece, introduciremos la información sobre el trabajo realizado en dicho periodo de tiempo.

Una vez rellenada la información relativa a la imputación en la tarea del trabajo realizado no computado anteriormente tenemos que pinchar el botón Resolver.

De esta forma se resuelve la tarea.

Las métricas del proyecto se guardarán dentro de la carpeta del proyecto en Proyecto/Documentacion/1.Gestionproyecto/1.4.Metricas. Las métricas de este proceso en concreto se almacenan en la Hoja DE.

1. Entra en Jira en el navegador de incidencias. Realiza una query simple y selecciona todas las tareas del proyecto.

• project = ClaveDelProyecto
• Disciplina-Proceso = Desarrollo-DE-Organizar el código

Pulsa el botón Search

Usa la Plantilla de Seguimiento tal y como se indica en el apartado Calcular tiempos con Jira.

Número de paquetes de código fuente totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. Ir al informe JavaNCSS, en este informe nos muestra todos los paquetes de código fuente del proyecto, solo hay que contar las filas de la tabla.

Número de clases totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de JavaNCSS aparecen el número total de clases de código fuente.

Número de métodos o funciones totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de JavaNCSS aparecen el número total de funciones en el código fuente.

Número de Javadocs del código fuente al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de JavaNCSS aparecen el número total de javadocs del código fuente.

Número de lineas de código fuente totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de JavaNCSS aparecen el número total de NCSS del código fuente.

El valor del NCSS, no es el del numero de lineas de un fichero de código fuente, sino el número de lineas de código fuente, eliminando comentarios, javadoc y lineas en blanco.

Número de páginas web totales al final de un Sprint o Release.

1. Tendremos que contar el número de ficheros con extensión XHTML y HTML del proyecto.

Número de clases de test unitarios totales al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Ir al informe TestNG, en este informe nos muestra los paquetes de código con test.
4. Seleccionamos en cada enlace referente a un paquete de código de test. En la página a la que se navega, aparecen dos tablas, en la primera aparecen las clases de Test, en la segunda aparecen los test ejecutados en el paquete.
5. Para el calculo de la métrica, hay que contar las filas de la primera tabla.

Número de test totales que hay en las clases de test unitarios al final de un Sprint, Build o Release.

1. Tenemos que dirigirnos al despliegue de la aplicación en Jenkins.
2. Ir a la página del proyecto comprobar que esta la ejecución del Sprint, Build o Release.
3. Entrar en el informe del Sprint, Build o Release.
4. En el resumen de TestNG aparecen el número total de test.

Para el calculo de las métricas de Base de Datos, tenemos que dirigirnos al SVN a la carpeta del proyecto en '/Proyecto/Fuentes/BD' como se indica en el Plan de Gestión de la Configuración. En esta carpeta tendremos diferentes carpetas para organizar los diferentes artefactos de base de datos.

Número de tablas totales al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Tablas' y contar el número de ficheros.

Número de vistas totales al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Vistas' y contar el número de ficheros.

Número de funciones y procedimientos totales al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Funciones' y contar el número de ficheros.
2. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Procedimientos' y contar el número de ficheros.
3. La suma de los dos cálculos anteriores nos da el número de total.

Número de paquetes totales que contienen funciones y procedimientos al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Paquetes' y contar el número de ficheros con extensión 'PKS'.

Número de paquetes totales que contienen funciones y procedimientos al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Paquetes'.
2. Para cada fichero con extensión 'PKS', tenemos que contar el las funciones y procedimientos.
3. La suma de los cálculos anteriores nos da el número de total.

Número de triggers totales al final de un Sprint o Release.

1. Nos tenemos a la carpeta '/Proyecto/Fuentes/BD/Vistas'.
2. Para cada fichero correspondiente a una tabla, lo abrimos y contamos el numero de triggers.
3. La suma de los cálculos anteriores nos da el número de total.

Tenemos dos clientes de SVN a disposición de los desarrolladores: Subeclipse en el IDE Eclipse y TortoiseSVN desde el Explorer de Carpetas.

Utilizaremos el cliente de SVN que esta disposición de los desarrolladores en el IDE Eclipse llamado Subeclipse. Seguiremos los siguientes pasos:

1. Lo primero que tenemos que hacer es realizar una sincronización del proyecto con el repositorio SVN para comprobar los posibles conflictos (marcados en rojo) que se pueden producir. Esto lo realizamos Seleccionando el proyecto y abriendo el menú contextual Team –> Syncronize with Repository, que nos llevara a la perspectiva de sincronización.
2. Una vez solucionados los conflictos, pasamos a realizar el commit, donde seleccionamos los ficheros a subir y abrimos el menú contextual seleccionando la opción Commit.
3. Nos aparece una ventana donde podemos repasar los ficheros seleccionados y añadir el comentario asociado donde se debe de indicar el JIRA asociado a la tarea.

Utilizaremos el cliente de SVN que esta disposición desde el Explorer de Windows llamado TortoiseSVN. Seguiremos los siguientes pasos:

1. Lo primero que tenemos que hacer es dirigirnos a la carpeta que según el plan de configuración contiene los artefactos de la base de datos en nuestro checkout del proyecto, mediante el Explorador de Carpetas.
2. Ahora tenemos que realizar una comprobación para ver si se ha modificado algún artefacto y comprobar los posibles conflictos.
3. Una vez solucionados los conflictos, pasamos a realizar el commit, donde seleccionamos la carpeta raiz que contiene los artefactos de la base de datos y abrimos el menú contextual seleccionando la opción SVN Commit
4. Nos aparece una ventana donde podemos repasar los ficheros seleccionados y añadir el comentario asociado donde se debe de indicar el JIRA asociado a la tarea.