Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Archivos por Etiqueta: Software Quality

Sonar PDF Plugin 1.0 released

Hace unos días se ha publicado Sonar PDF Plugin 1.0, con una mejora fundamental: el documento PDF se almacena en la base de datos tras cada análisis y puede descargarse desde la GUI de Sonar.

PDF Download from Sonar GUI

También es posible configurar el tipo de reporte desde la interfaz de administración de Sonar:

PDF report type configuration

Se  puede encontrar información más detallada (instalación y uso) en la documentación del proyecto.

La calidad del código fuente como punto de partida

Cuando hablamos de calidad del software podemos hacerlo a muchos niveles: rendimiento, mantenibilidad, cumplimiento de requisitos funcionales, estabilidad, proceso de construcción,… y el que en mi opinión constituye la base, el código fuente.

Desde mi punto de vista la calidad del código fuente se extiende hasta otros niveles, por ejemplo, el rendimiento. De hecho, cuando nos disponemos a realizar una auditoría de rendimiento el punto de partida siempre debería ser el código fuente, éste nos puede dar pistas sobre los puntos débiles de la aplicación, los cuales orientarán las pruebas de rendimiento.

Supongamos un caso de uso simple (y muy común): una aplicación web escrita en Java que permite la subida de un fichero a través de un formulario, cuando este stream de datos llega al servidor se carga en memoria y posteriormente se almacena en base de datos. Si tenemos la mala suerte de que al programador se le “olvide” cerrar el stream después de usarlo y por algún motivo esta memoria no sea liberada por el recolector de basura de la JVM, entonces tenemos un problema: ese espacio de memoria no se liberará NUNCA.

La herramienta PMD detecta, entre otras muchas, una mala práctica de programación consistente en no cerrar correctamente los recursos (streams de ficheros, conexiones a bases de datos, etc) después de usarlos. Si la utilizásemos para analizar el código fuente de la aplicación descrita anteriormente nos indicaría que no se está cerrando un recurso. Si lo que buscamos son causas de un problema de memoria en tiempo de ejecución, vamos en el camino correcto. Definiremos una prueba que ejecute el caso de uso en cuestión y la ejecutaremos simulando N usuarios, al mismo tiempo podemos monitorizar el servidor de aplicaciones y verificar que realmente estamos ante un memory leak.

Sonar PDF Reporter, tu código tiene algo más que decir

La empresa en la que trabajo (GMV) está apostando con fuerza por el Software Libre, fruto de esta apuesta es la contribución a varios proyectos Open Source, entre ellos Sonar. Cuando se me dió esta oportunidad, no tuve dudas, quería aportar algo a este magnífico proyecto, del cual llevábamos sacando partido bastante tiempo.

Desde hace algún tiempo trabajo (entre otras cosas) para desarrollar un nuevo módulo en Sonar, Sonar PDF Reporter. El objetivo del módulo es añadir una nueva funcionalidad a Sonar que permita la explotación en forma de entregable de gran parte de la información que nos ofrece esta herramienta en su interfaz web.

El módulo genera un archivo PDF que contiene:

  • Visión general de la calidad del código de todo el proyecto.
  • Información concreta por módulos funcionales: métricas y medidas obtenidas a partir combinaciones de las métricas.
  • Información general del proyecto: versionado, estructura de módulos, descripción, etc

Además de ser un módulo integrado en Sonar, durante el diseño siempre tuve en mente el posible uso del módulo de forma independiente, es decir, ofrecer la posibilidad de explotar la información que Sonar proporciona desde nuestra propia aplicación, por ello se ha hecho uso de Web Services API de Sonar.

sonar

Sonar PDF Reporter Design

Quedan bastantes retoques y mejoras por realizar, pero puedes descargar un PDF de ejemplo con los reportes del propio proyecto Sonar, y ver en primicia el resultado ;)

The Agile Quality Concept

Como todo, la calidad del software puede ser entendida y tratada de formas muy diferentes, que en teoría buscan el mismo objetivo. Estoy presenciando personalmente cómo chocan de frente dos enfoques, el ágil y el pesado, pero ¿qué caracteriza a cada uno de estos enfoques?.

Un enfoque pesado se caracteriza por seguir ciertas normas predefinidas y comunes para todos los proyectos, independientemente de la naturaleza de los mismos. En mi opinión, un enfoque ágil debe aportar valor en los aspectos que realmente son importantes para cada proyecto concreto.

Enfoque “ágil” de la calidad

  • Filosofía de aporte de valor. Como comentaba antes el aporte de valor a los aspectos realmente importantes de cada proyecto es la base de un enfoque ágil. No existen unas normas perfectamente definidas en un libro de 300 páginas, la norma es: si aporta valor al equipo de proyecto y al cliente, se hace (siempre dentro de los límites económicos del proyecto, porque como sabemos, la calidad cuesta dinero).
  • Documentación útil. La documentación es una tarea que consume mucho tiempo, y por tanto hay que dosificarla. Solamente se generará la documentación que realmente sea útil durante el desarollo y mantenimiento del proyecto, no tiene sentido la redacción de pesados documentos que en el mejor de los casos acaban en el cajón del cliente sin haber sido leídos. Es fundamental mantener la documentación, ya que es un entregable que evoluciona al mismo ritmo que el desarrollo en una metodología ágil, la perdida de coherencia en la documentación puede ser una gran fuente de errores (y por tanto de trabajo extra).
  • Software que funciona. Una medida de calidad será el software que funciona, y además funciona reflejando el catálogo de requisitos en la implementación, y por supuesto, siendo la implementación correcta a nivel técnico. La piedra angular para asegurar estos dos aspectos es el testing. Si se consigue todo lo anterior, posiblemente otra medida de calidad será la enhorabuena del cliente.
  • Calidad del código fuente. Este es uno de los aspectos que más se dejan de lado en las metodologías pesadas. Cuando uno se enfrenta a un proyecto cuyo código es de calidad, las cosas son más fáciles. La calidad del código comprende aspectos como el seguimiento de una guía de estilo y codificación, evitar el uso de formas de programación que pueden provocar errores potenciales, mantener un código usable, legible, extendible, eficiente, portable y correctamente versionado para su posterior mantenimiento.
  • Integración continua. En un enfoque ágil del aseguramiento de la calidad no puede faltar un sistema de integración continua. Con él automatizaremos las pruebas definidas para el proyecto, compilaremos el código integrando los cambios efectuados por lo desarrolladores, generaremos documentación periodicamente que puede ser consultada incluso por el cliente y mantendremos el código sano en todos los sentidos.

En mi opinión estos son los puntos fundamentales de un enfoque ágil del aseguramiento de la calidad.

Segundo día en expo:QA

El segundo (y último) día de conferencias en expo:QA, al igual que el primero, no me ha defraudado. Me vuelvo a Sevilla muy satisfecho. De las conferencias de hoy destaco dos:

Integración Continua (Eric Pugh, Open Source Connections)

Eric Pugh nos ha contado cómo implantar un sistema de integración continua teniendo en cuenta los contratiempos que encontraremos (tanto técnicos como “sociales”), entendiendo como contratienpos sociales por ejemplo el hecho de que los programadores vean el sistema de IC como una herramienta que sólo resalta los errores que se cometen, cuando en realidad es todo lo contrario, les ayuda a realizar mejor su trabajo. Incluso les ahorra tiempo cuando hay que preparar una demo al cliente, todo se reduce a lanzar un build en IC.

Eric comentaba que la IC será un “radiador de información útil para todo el equipo del proyecto”. Por último vimos una demostración con Hudson. Destacar el esfuerzo de Eric por hacer la exposición en español.

Methodology for performace testing (Edgardo Greising)

En esta charla Edgardo ha compartido la metodología usada en el laboratorio de Ensayos de Plataformas del CES. Esta metodología consiste en:

  • Definición de escenarios: infraestructura, datos de prueba, número de usuarios concurrentes, etc
  • Automatización: determinar el guión de ejecución
  • Reproducción del entorno de producción: hardware, software, red (en caso de que queramos medir tiempos)
  • Monitorización: a nivel software y a nivel humano (usuarios reales interactuando con la aplicación en paralelo con cientos de usuarios virtuales)
  • Reportes: recomendando el uso de gráficas para encontrar patrones de comportamiento