A continuación se definirá el Plan de Calidad del proyecto, el objetivo de este es definir una serie de procedimientos y reglas que ayuden a que el proyecto satisfaga las necesidades por las cuales se emprendió. Concretamente los procedimientos que formarán parte de la gestión de la calidad serán los procesos de Seguimiento y control del proyecto y el de Calidad de código.
Por último se mostrarán los resultados de calidad de código obtenidos al final del proyecto.
5.4.1. Seguimiento y control
Debido a que la duración del proyecto es amplia y a que el tiempo de rectificación es muy pequeño es necesario definir varias actividades de seguimiento en la planificación del proyecto, con el fin de obtener un feedback del estado del proyecto en tiempo para aplicar cambios. Como ya se dijo en el apartado de Gestión Temporal, el proyecto sigue un ciclo de vida en cascada en el que podemos diferenciar claramente tres fases, Análisis, Diseño y Desarrollo/Pruebas. Utilizaremos está división en fases para establecer las actividades de seguimiento y control al final de cada una. Además en medio de la fase de Desarrollo/Pruebas también se realizará un seguimiento, esto es así debido a que la duración de la fase de Desarrollo/Pruebas es muy amplia.
Cada actividad de seguimiento constará de las siguientes tareas: • Evaluación de cambios
Se revisará el Historial de cambios para evaluar todas aquellas peticiones de cambio que aún no hayan sido evaluadas. En el caso de que existan peticiones de cambio aceptadas se deberán de realizar, para ello a la hora de planificar las tareas de seguimiento y control se dejará un pequeño margen de tiempo.
• Seguimiento de riesgos
Es importante identificar los riesgos del proyecto en una fase inicial del proyecto pero más importante es realizar un seguimiento del estado de estos e identificar nuevos. En las tareas de seguimiento de riesgos se evaluarán aquellos riesgos a los que se les esté haciendo un seguimiento con el fin de ver si alguno se produjo y aplicar el plan de corrección.
Además se eliminarán aquellos riesgos que ya no estén activos en el proyecto y se podrán identificar nuevos.
La identificación de los riesgos se basará en las listas de riesgos identificados en anteriores proyectos de la empresa y en el análisis de los elementos del proyecto y sus posibles amenazas. El historial de riesgos se podrá consultar en el documento [MM-HR]-HistorialRiesgos.
• Reunión con directores
La última tarea de seguimiento será realizar una reunión con los directores del proyecto. El objetivo de estas reuniones será primero informar a los directores del estado del proyecto y segundo obtener su visión del proyecto así como las peticiones de cambio oportunas.
Para organizar las reuniones el proceso será el siguiente:
• Se enviará la documentación a los directores vía email a medida que se vaya generando, con el fin de dar un margen de tiempo para leerla antes de la reunión.
• Se compartirá un documento de texto online con los directores en el que se represente el Acta de reunión.
Las actas de reunión deberán tener los siguientes apartados: o Fecha y lugar de la reunión.
o Nombre de los convocados.
o Objetivos de la reunión, debe de ser el índice que guíe la reunión. o Conclusiones, permitirá tener un resumen de la reunión.
5.4.2. Calidad de código
5.4.2.1. Formato
El Módulo de monitorización se desarrolla dentro del entorno de desarrollo del Proyecto de Interoperabilidad, compartiendo recursos como son el repositorio de código y módulos comunes, esto provoca que para desarrollar ciertas funcionalidades haya que modificar módulos del Proyecto de Interoperabilidad.
La generación de código no puede ser descontrolada y debe de seguir unas reglas de formato, con el fin de facilitar la integración de los cambios con los demás desarrollos que se produzcan en la Plataforma de Interoperabilidad. De no seguir unas reglas de formateado, a la hora de integrar código nos encontraríamos con numerosos conflictos de código provocados por diferencias de formato.
Para que todos los desarrollos sigan un mismo formato se hará uso de las plantillas de formato que ofrece el entorno de desarrollo Eclipse. A continuación se muestra la configuración necesaria, dividida por lenguaje de programación. Para aquellos lenguajes que no se especifica la configuración deberá de definirse la configuración por defecto.
JAVA
En Windows->Preferences->Java->Code Style->Editor se importará la plantilla [MM]-CodeStyle- Formatter situada en el directorio 1.Módulo de monitorización/2.Gestión proyecto/5.Gestión de calidad.
Con el fin de que el formateado de código sea una tarea automática se asociará la acción de Guardar con la de Formatear, de manera que cada vez que se guarde un archivo se le establezca el formato definido. En Windows->Preferences->Java->Editor->Save Actions definimos la siguiente configuración:
Ilustración 8.Configuración guardar-formatear.
HTML
En Windows->Preferences->Web->HTML Files->Editor establecemos la configuración como figura en la siguiente imagen:
En el apartado de Elementos en línea debemos establecer solo las siguientes etiquetas: a,abbr,acronym,b,basefont,big,br,cite,em,Font,i,img,q,s,select,small,strike,strong,sub,sup,title 5.4.2.2. Métricas y convenciones
Para revisar la calidad del código implementado en función de métricas y convenciones utilizaremos la herramienta de código libre Sonar. Sonar es una de las plataformas más populares para medir la calidad del código, permitiendo obtener métricas sobre diferentes lenguajes de programación. Su funcionamiento se basa en el uso de otras herramientas como PMD o Checkstyle.
En el entorno de desarrollo de la Plataforma de Interoperabilidad se cuenta con un servidor Sonar desplegado en la red interna del proyecto. Para integrar los proyectos del Módulo de Monitorización con este servidor se instalará el plugin de Sonar para Eclipse y se configurará la url del servidor.
Una vez configurado el plugin de Sonar podremos analizar cualquier proyecto utilizando el comando de Maven sonar:sonar, este comando subirá el código del proyecto al servidor Sonar. Con el proyecto importado al servidor Sonar podremos acceder a través de un navegador web y ver las diferentes métricas del código.
De toda la información que nos ofrece Sonar la que vamos a tener en cuenta van a ser la Complejidad ciclomática, Duplicación de código y las violaciones de buenas prácticas de programación.
Complejidad ciclomática
La complejidad ciclomática es una métrica que nos aporta medición cuantitativa de la complejidad lógica de un programa.
Sonar, calcula la complejidad ciclomática a través de un contador. Cuando el flujo de una función se altera, es decir, se produce un salto, este contador de complejidad aumenta en 1. Cada función tiene como mínimo una complejidad de 1.
En el caso de Java el contador aumenta cada vez que se encuentra con alguna de las siguientes sentencias:
if, for, while, case, catch, throw, return, &&, ||, ?, else. Cabe destacar que las llamadas a getters y setters no aumentan el contador.
Sonar aporta información de la complejidad total, de la complejidad de clase y de la complejidad de método. Para el Módulo de Monitorización se establecerá un máximo de 2.5 de media de complejidad en los métodos. El motivo de fijar la complejidad sobre los métodos y no sobre las clases o sobre el sistema en general es facilitar las posibles acciones de corrección, ya que, a través de Sonar podemos identificar aquellos métodos cuya complejidad es más crítica, por lo que tendríamos el problema mucho más acotado. Además se establece un valor de 2.5 con el fin de al menos igualar la complejidad del resto de módulos ya implementados de la Plataforma de Interoperabilidad.
Duplicación de código
Uno de los puntos que más perjudicial a la hora de que un código sea fácil de mantener son las duplicaciones de código. Sonar aporta información acerca de la cantidad de líneas duplicadas, se utilizará esta información para identificar código que pueda ser reutilizado y así evitar la duplicación.
En ciertas ocasiones la duplicación de código será inevitable por lo que se aceptará como máximo un 5% de código duplicado.
Convenciones de código
Sonar cuenta con una serie de reglas que permiten evaluar el cumplimiento de convenciones de programación Java, como pueden ser nomenclaturas, números mágicos, declaraciones, visibilidad de variables…
Se deberán cumplir las convenciones de programación Java en al menos un 90%, siguiendo el grado de cumplimiento de los anteriores módulos de la Plataforma de Interoperabilidad.
5.4.3. Resultados
A continuación se muestran los resultados obtenidos a la finalización del proyecto acerca de la calidad de código. La revisión de la calidad de código se hace por proyecto. El Módulo de Monitorización se divide en cuatro proyectos:
• Monitorización-Model: Contiene el código de los servicios del Módulo de Monitorización.
• Monitorización-Portlet: contiene el código de la Consola de monitorización. • Análisis-Proactivo-Batch: contiene el código del batch que realiza el cálculo
de los niveles de servicio y analiza su tendencia.
• Monitorización-Batch: contiene el código del batch que monitoriza los componentes de la Plataforma de Interoperabilidad.
Monitorizacion-Model
Número de líneas de código 4188
Convenciones código Java 93.4%
Media complejidad ciclomática métodos 2.0
Duplicación código 0.9%
Tabla 17. Resultados calidad código Monitorizacion-Model
Monitorizacion-Portlet
Número de líneas de código 3710
Convenciones código Java 91.3%
Media complejidad ciclomática métodos 1.5
Duplicación código 1%
Tabla 18. Resultados calidad código Monitorizacion-Portlet
Análisis-Proactivo-Batch
Número de líneas de código 120
Convenciones código Java 97.5%
Media complejidad ciclomática métodos 2.3
Duplicación código 0 %
Tabla 19. Resultados calidad código Análisis-Proactivo-Batch
Monitorización--Batch
Número de líneas de código 140
Convenciones código Java 97.9%
Media complejidad ciclomática métodos 2.1
Duplicación código 0%
Introducción
En este apartado de Análisis comenzaremos definiendo los parámetros concretos que se van a monitorizar y como se realizará el proceso de monitorización, para terminar reflejando la funcionalidad del sistema a través de los casos de uso y los requisitos.
6.1. Monitorización
Ilustración 10. Estructura monitorización PLATINT
Para monitorizar la Plataforma de Interoperabilidad la dividiremos en componentes. Los componentes pueden ser o tareas programadas o servicios de la PLATINT que fueran dados de alta para la monitorización.
A cada uno de los componentes se le medirán unos indicadores con el fin de obtener información acerca de su estado. Para el cálculo de los indicadores se utilizarán diversos procedimientos que serán ejecutados automáticamente. Cada procedimiento puede calcular uno o varios indicadores. Los procedimientos son asignados a los componentes, pudiendo configurar la frecuencia de ejecución del procedimiento para cada componente concreto. Los valores de los indicadores calculados serán guardados como registros.
Un procedimiento será cualquier implementación cuya entrada sea un componente y cuya salida sean registros de los indicadores que calcula ese procedimiento, con el valor que tengan en el momento para el componente introducido. Los procedimientos se agruparán en Perfiles de monitorización, de este modo, se facilitará la asignación de procedimientos a los componentes. Como ya hemos visto, a cada componente se le puede configurar la frecuencia con la que se le ejecuta cada procedimiento, aun así, los procedimientos tendrán una frecuencia por defecto. El valor de los indicadores para cada componente por sí solo no es suficiente para conocer el estado de un componente. Es necesario establecer una serie de umbrales para los indicadores de manera que se pueda conocer si el valor de un indicador está en un estado o en otro. En la siguiente ilustración se puede ver gráficamente el sentido de los umbrales de los indicadores:
Ilustración 11. Umbrales de indicadores
Para obtener una información más sencilla de interpretar, se establecen tres niveles de monitorización para los valores de los indicadores:
• Rojo: El indicador está en un valor crítico.
• Amarillo: El indicador está en un valor de semi-alerta, puede ser crítico si se repite varias veces.
• Verde: El indicador está en un valor correcto.
Se utilizarán los siguientes umbrales para definir en qué valor se encuentra cada indicador: • Umbral Bajo Medio: Establece el límite entre el nivel Rojo y el nivel Amarillo. • Umbral Medio Alto: Establece el límite entre el nivel Amarillo y el Verde.
Si un indicador tiene el valor exacto de uno de los umbrales, su nivel de monitorización será el Rojo o el Verde, dependiendo de qué umbral sea.
Al igual que ocurre en los procedimientos con su frecuencia, los umbrales de los indicadores también tienen unos valores por defecto y también se pueden modificar en función de cada componente.
Uno de los objetivos del MM es avisar ante situaciones de alerta de la PLATINT. Para gestionar estos avisos se utilizarán reglas. Las reglas de avisos permiten establecer qué aviso hay que enviar y a quién en caso de que un indicador se encuentre cierto número de veces en un nivel de monitorización para un componente. Por ejemplo, se puede tener una regla para el servicio de Consulta de Identidad con los siguientes valores:
Con la anterior regla lo que ocurrirá es que, cuando se monitoriza el servicio de Consulta de Identidad, si los 6 últimos registros fueron amarillos, se enviará un aviso con el mensaje a los destinatarios establecidos. Además de enviar un aviso se creará una incidencia en el MM con el fin de tener un registro de las alertas que fueron generadas.
Las incidencias tendrán un estado que podrá ser Resuelta o Sin Resolver. Al crear una incidencia su estado siempre será Sin Resolver. Las incidencias se podrán resolver a través del portlet del MM.
6.1.1. Procedimientos e indicadores
A continuación se identifican los procedimientos e indicadores concretos que se van a utilizar en la primera versión del MM para vigilar el estado del sistema.
Procedimiento de Ping a Servicio
El procedimiento Ping de Servicio solo se aplicará en la monitorización de los servicios. Este procedimiento se basará en comprobar si los distintos webservices de los servicios están activos. El indicador calculado será:
• Estado del Servicio: podrá tomar los valores activo o no activo. En caso de que alguno
de los webservices del servicio no esté activo, el indicador Estado de Servicio se considerará no activo.
Procedimiento Trazas de Servicio
El procedimiento de Trazas de Servicio será utilizado en la monitorización de los servicios. Analizando las peticiones que se realizan a los distintos servicios de la PLATINT podemos obtener distintos indicadores de los servicios.
Para extraer información acerca de las peticiones que se realizan a la PLATINT la fuente de información serán las trazas generadas por esta. Se deberán modificar las trazas que se generan
Indicador: Tiempo petición Nivel monitorización: Amarillo Máx. Repeticiones: 6 Mensaje:
El servicio Consulta de Identidad presenta un tiempo de petición demasiado alto.
Destinatarios:
durante la petición a un servicio para que aporten la información necesaria para poder calcular los siguientes indicadores:
• Estado petición: toma los valores correcta o incorrecta en función de si la petición dio
error o no. En caso de que una petición dé error este será el único indicador monitorizado para esa petición, ya que, al ser una petición errónea, el resto de indicadores carecen de valor.
• Tiempo petición: tiempo total que se tarda en tramitar una petición.
• Tiempo Conector Ida: tiempo que tarda el conector en validar y preparar la petición para
enviarla al bus.
• Tiempo Conector Vuelta: tiempo que pasa la respuesta a la petición en el conector.
• Tiempo Bus Ida: tiempo que tarda el re-encaminamiento de la petición en el bus.
• Tiempo Bus Vuelta: tiempo que tarda la respuesta en el bus.
• Tiempo Servicio Final: tiempo que tarda la petición en ser respondida por el servicio
final.
Procedimiento de Trazas de Tarea
El procedimiento de Trazas de tarea solo se aplicará para la monitorización de las Tareas programadas. Este procedimiento calculará el indicador:
• Funcionamiento tarea: podrá tomar los valores correcto o incorrecto en función de si se
ejecuta correctamente la tarea o no.
Para cumplir con el procedimiento, las tareas programadas deberán generar trazas que informen acerca del estado de su ejecución.
6.1.2. Niveles de servicio
Los procedimientos e indicadores que acabamos de ver son los identificados para una primera versión del Módulo de Monitorización. No obstante, el Módulo de Monitorización se desarrollará de forma que se facilite la adición de más procedimientos e indicadores.
Además, para cada indicador se calculará un nivel de servicio. Los niveles de servicio son un resumen de los valores de los indicadores en un determinado tiempo.
El nivel de servicio para el indicador Tiempo petición ofrece por ejemplo, la velocidad media que tarda en ser resuelta una petición. Para calcularlo se mira el valor de los indicadores en la última semana (rango de tiempo por defecto) y se calcula la media del total de valores registrados.
6.2. Consola de monitorización
Con el fin de acercar la funcionalidad de la monitorización al usuario se dispondrá de una Consola de monitorización accesible para usuarios autorizados en la sección de administración del portal. La Consola de monitorización deberá contar con una visión resumida del estado de los componentes. Se mostrará un resumen de los principales indicadores de todos los servicios como pueden ser el número de servicios activos, la tasa de errores general o el tiempo medio
de respuesta de los servicios. Además la consola facilitará el seguimiento de las últimas incidencias.
A través de la Consola de monitorización se podrán ver los servicios del Catálogo de Productos para activar o desactivar su monitorización. Al activar la monitorización de un servicio por primera vez se seleccionará el perfil que se le quiere asignar.
De cada servicio se podrán observar datos del servicio como nombre, estado servicio, estado monitorización, organismo responsable, perfil, incidencias y registros. A cada servicio se le podrán configurar los valores de la frecuencia con la que se ejecuta cada procedimiento, los umbrales de los indicadores, subir una plantilla para la petición de prueba y asignar o restablecer los valores de un perfil.
Como parte de la monitorización online, la Consola de monitorización permitirá realizar un ping a los servicios para conocer el estado de todos sus consumidores y productores. Si el servicio cuenta con datos de prueba y una plantilla de prueba configurada se podrá realizar una petición de prueba al servicio.
Otra de las funcionalidades que se deberá ofrecer a través de la Consola de monitorización es un buscador de incidencias y registros. A través de este buscador se podrán ver las incidencias y registros del sistema, hacer búsquedas por los campos más relevantes y exportar los datos a un fichero csv.
Por último, la Consola de monitorización deberá permitir la administración de la configuración de monitorización y la administración de las reglas. De la configuración de la monitorización se podrán modificar la fecha de inicio del análisis y los perfiles. Las reglas se podrán crear, modificar o eliminar. Para crear una regla será necesario indicar el componente, indicador, nivel de monitorización, máximo de repeticiones para que salte la regla, mensaje de aviso y la lista de destinatarios y/o lista de emails.