El objetivo de este proceso es el controlar la calidad interna del producto que se entregará en la release. Con la calidad interna entendemos aspectos que no son visibles/detectables por el usuario final (no afectan a la funcionalidad directamente), pero que pueden afectar en otros aspectos. Esos aspectos, los desglosamos a continuación:

• Calidad del código. Cuanto mayor sea la calidad del código (en cuanto a legibilidad, modularidad, documentación interna) más fácil será su mantenimiento. Ese mantenimiento tendrá que realizarlo el mismo grupo de trabajo, por lo tanto es importante minimizarlo, para que un cambio en el software pueda ser realizado lo más rápidamente posible. Para ello atenderemos a los Resultados de CheckStyle y de FindBug. Incluso aparecerán en los resultados puntos relacionados con el rendimiento y la corrección, que estarían dentro del ámbito externo (detectables por el usuario).

• Seguridad. Cuando exponemos aplicaciones al exterior (sobre todo si son aplicaciones webs), tenemos que atender a que no sean vulnerables a ataques externos. Para ello tenemos la Plantilla de Seguridad con los puntos que hay que cumplir para asegurar que la aplicación es segura.

• Numero y calidad de Test Unitarios. En la fase de desarrollo se deben de haber trabajado con test unitarios para garantizar el correcto funcionamiento de los componentes en desarrollo y agilizar esa etapa de desarrollo. Con los Resultados de Cobertura, tendremos ponderado la calidad de esos tests unitarios realizados en la fase de desarrollo (por el numero de lineas que cubren y el número de tests).

En la disciplina de requistos, en el documento de requisitos no funcionales, se habrá especificado qué grado de calidad interna mínima debe de cumplir el código a entregar. Una vez pasado las plantillas se evaluará qué cambios, hay que realizar sobre el código antes de liberar la release y se pasará al proceso de control de cambios.

Los siguientes son los roles participantes en este proceso:

Comprueba que se ha implementado un tiempo máximo de inactividad de la sesión (timeout) en la aplicación (p.e. 30 minutos), de manera que, si un usuario que ha entrado en la aplicación supera el timeout de inactividad (p.e. está 30 minutos sin interactuar con ella), la aplicación debe cerrar automáticamente la sesión (haciendo un logout de la aplicación), de manera similar a si el usuario pincha directamente en la opción “Salir” de la aplicación).

Este mecanismo de seguridad mediante timeout de sesión es obligatorio de conformidad con el ENS.

Existe una guía técnica que explica cómo Implementar el Timeout de la Sesión Web

Si no se indica timeout de sesión en el web.xml de la aplicación, automáticamente cogerá el que SISTEMAS tiene configurado en weblogics y tomcats, que actualmente (19-12-2018) es de 1h, siempre que esté activo. Confírmalo con SISTEMAS.

Si la aplicación usa SSO/CAS, para la sesión del CAS también existe un timout, que actualmente (19-12-2018) es de 4h. Confírmalo con TELEMÁTICA.

En ATICA existe una Normativa de Desarrollo de Aplicaciones Web Seguras desde Julio del 2008. Esta normativa se basa en la Guía de Revisión de Código de la fundación OWASP, incluyendo una serie de puntos de verificación de la seguridad de la aplicación/módulo. Además, para cada punto de verificación de la seguridad de la aplicación/módulo, se incluyen anotaciones relativas a cómo FUNDEWEB puede ayudar a validar el citado punto de verificación.

Con el objetivo de verificar que se está cumpliendo dicha normativa, se debe de completar la plantilla de seguridad que se proporciona con MEDEA:

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

Punto por punto, y marcando aquellos requisitos de seguridad que se haya verificado que se cumplen. En aquellos que no se pueda cumplir, indicar en las Observaciones el motivo del NO cumplimiento.

Las aplicaciones Web hechas en ATICA, deben cumplir la actual Normativa nacional y europea sobre Accesibilidad Web, para lo que los desarrolladores pueden usar la Guía de accesibilidad en aplicaciones FundeWeb.

Cuando usamos componentes JSF esta tarea puede resultar difícil, pues existen componentes cuyo código HTML no cumple con el estándar HTML o XHTML del W3C (o los estilos asociados al componente no cumplen el estándar CSS). Esto NO debe ser una excusa para despreocuparnos de la accesibilidad, al contrario, debemos poner las peticiones de cambios que sean necesarias a los fabricantes de los componentes JSF que estemos usando en cada momento, y que no cumplan los estándares del W3C. Para ello debemos contactar con MNCS.

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

En la Guía de accesibilidad en aplicaciones FundeWeb te recomendamos herramientas para analizar la accesibilidad de cada pantalla de tu aplicación web. Algunas de estas herramientas te permitirán generar informes de accesibilidad que podrás adjuntar al artefacto “ControlRequisitosAccesibilidad”, o directamente a la tarea que hayas creado en Jira para testear la accesibilidad de tu aplicación.

También puedes consultar la Wiki de Accesibilidad, donde además de la guía del párrafo anterior, tienes la Guía de Validación de la Accesibilidad Web del Observatorio de Accesibilidad adaptada a WCAG 2.1, así como el Real Decreto de Accesibilidad Web.

Finalmente, puedes consultar la Lista Completa de Herramientas que propone el W3C.

Para completar el artefacto “ControlRequisitosAccesibilidad” tienes que rellenar los apartados que contiene:

2.1. Rellenar apartado “Estándar HTML de W3C”, en caso de que las páginas estén escrita en HTML. Para ello disponemos de la barra de herramientas Web Developer Toolbar, para el Firefox. En esa barra, pulsar la opción:

Ojo : Para que funcione hay que trabajar con una dirección desde la que se tenga acceso desde el exterior (ya sea de producción o de un equipo local de desarrollo poniendo la ip local).

2.2. Rellenar apartado “Estándar XHTML de W3C”, en caso de que las páginas estén escrita en XHTML. Usaremos la misma herramienta y opción que en el caso anterior.

2.3. Rellenar apartado “Estándar CSS de W3C”.Para ello disponemos nuevamente de la barra de herramientas Web Developer Toolbar, la opción:

2.4. Rellenar apartado “Estándar WAI de W3C. Doble A”. Algunos puntos de esta lista de recomendaciones de accesibilidad serán automatizables otros habrá que pasarlos a mano. Podemos volver a hacer uso de la Web Developer Toolbar con la opcion

y para el punto de la normativa referido al contraste de color, tenemos la herramienta juicy-studio, que es un add-on del firefox. Para pasarla ejecutar la opción:

Un resultado del proceso de “Integrar Continuamente”, son los resultados del control de calidad del Jenkins. A parte tenemos los resultados del control de seguridad y de acesibilidad de las tareas anteriormente ejecutadas.

En esta tarea evaluaremos estos resultados para decidir si es necesario hacer cambios en el proyecto o no. En caso afirmativo usaremos el JIRA para gestionar estas incidencias.

Para esta tarea se deben de dar de alta un JIRA con los siguientes datos

En Jenkins cogeremos la ultima ejecución

y comprobaremos los resultados del findbug.

De entre estos prestaremos especial atención a los de prioridad alta, ya que son errores potenciales de codigo. Para los que consideremos relevantes abriremos un JIRA con los cambios a realizar por los desarroladores o para que pasen a ser estudiados por el analista. De la siguiente forma:

En Jenkins cogeremos la ultima ejecución y comprobaremos los resultados de checkstyle.

De entre los resultados prestaremos especial atención a los de nivel alto, que tendrán que ver con la convención de código java, el número de comentarios realizados en las clases y la complejidad de las mismas.

Habrá que tener en cuenta que hay clases autogeneradas o de servicio, en las que se puede incumplir alguna de estas normas, ya que son meros contenedores de datos o interfaces para el acceso. Se intentará que estas clases no sean tratadas por el CheckStyle, dentro de lo posible.

Para los que consideremos relevantes abriremos un JIRA con los cambios a realizar por los desarroladores o para que pasen a ser estudiados por el analista. El JIRA tendrá a siguiente forma:

La Cobertura está orientada a evaluar el grado de calidad de los test, en el sentido del código que son capaces de probar.

Para ver el grado de cobertura nos situaremos en la última ejecución y seleccionaremos “Informe de Cobertura”.

Lo primero es ver que el nivel de cobertura esté en un valor aceptable. No es necesario que TODO el código esté probado con test unitarios (100%). Ni necesario, ni aconsejable ya que hay codigo cuya funcionalidad está ligada a la vista, que no se podrá probar con test unitarios. por lo tanto tenerlos sería absurdo. Sí que tenemos que intentar que el código con más parte de lógica esté probado correctamente.

La segunda parte es la gráfica de tendencias. Intentaremos que se mantenga estable, indicando que conforme avanza el desarrollo también avanza la creación de test unitarios.

Si consideramos que hay pocos tests o que hay partes relevantes de software sin suficientes tests unitarios abriremos un JIRA con los cambios a realizar por los desarroladores o para que pasen a ser estudiados por el analista. El JIRA tendrá la siguiente estructura:

Una vez rellenada la plantilla de seguridad, si hay puntos que no han sido cubiertos por la aplicación correctamente, abriremos un JIRA con los cambios a realizar por los desarroladores o para que pasen a ser estudiados por el analista, para que evalúe si se pueden evitar.

Una vez rellenada la plantilla de accesibilidad, si hay puntos que no han sido cubiertos por la aplicación correctamente, abriremos un JIRA con los cambios a realizar por los desarroladores o para que pasen a ser estudiados por el analista, para que evalúe si se pueden evitar.

• NOTAS:
  • XXX: Código del proyecto.
  • 1.2.3: Número de version del documento.

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

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Calidad del Software-QS-Controlar la Calidad Interna

Pulsa el botón Search

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

Negrita

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-QS-Controlar Calidad Interna
• Las etiquetas de MEDEA en JIRA deben llevar el prefijo “mda-” q las identifique, y deben escribirse siempre en minúsculas, de modo q la etiqueta “PPS“ pasaría a ser “mda-pps”.

Pulsa el botón Search

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

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-QS-Controlar Calidad Interna
• label= PPA

Pulsa el botón Search

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

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

• project = ClaveDelProyecto
• Disciplina-Proceso = Requisitos-QS-Controlar Calidad Interna
• label= ER

Pulsa el botón Search

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

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-Crear componentes
• label=CI

Pulsa el botón Search

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