Metrica v3 es la actual metodología propuesta por el Ministerio de Administraciones Públicas español, como metodología oficial para la Planificación, Mantenimiento y Desarrollo de Sistemas de Información, pincipalmente en Instituciones Públicas españolas, donde es ampliamente utilizada y exigida por la mayor parte de las Comunidades, Ayuntamientos y otros Organismos públicos.

El punto de partida de Metrica se encuentra en una metología de desarrollo tradicional, donde cada una de las fases avanza la fase anterior formando un conjunto de actividades que han de ser ejecutadas en serie en su mayoría, contando además con diferentes interfaces específicos dedicados a temas accesorios como calidad, seguridad y gestión de la configuración.

Después de la experiencia que veo en los proyectos de desarrollo software con la administración pública, tanto local como estatal, la metodología Metrica va pidiendo una pronta actualización, que desde mi punto de vista puede resumirse en los siguientes puntos:

• Es una metodología muy pesada como para poder aplicarla de igual forma a proyectos de 2 meses o de 2 años. Quizás una metología menos pesada o de otro tipo (por ejemplo en espiral, SCRUM, XP o similar) encajaría mejor en proyectos pequeños, donde la sobrecarga dedicada a las labores accesorias no deben ser el principal volumen de trabajo del proyecto.
• Es una metodología tradicional, basada en la consecución de fases tradicionales, en la que todas las piezas deben estar muy bien encajadas para que se produzca un resultado general satisfactorio para todas las partes (el proveedor, el cliente y el usuario final). Está claro que la Administración Pública tiene unas características especiales, con las que a menos que todas estas partes se sientan conscientes del trabajo que deben realizar, que conozcan la propia metodología y las implicaciones que tienen en el resultado final, el proyecto siempre se va con seguridad de plazo, y por tanto de coste y posiblemente de nivel de calidad. Otras metodologías de desarrollo más ágiles pueden aportar una mayor interactividad entre todas las partes y una forma efectiva de atender modificaciones y cambios de requisitos que, no nos engalemos, casi siempre existirán.
• El usuario final de los sistemas de información a modelar normalmente tiene poca interactividad durante la evolución de su desarrollo, si bien es cierto que debe tener importancia su aportación en las fases de análisis, también es cierto que no vuelven normalmente a tener una aportación hasta las fases finales, ya de implantación del propio sistema. Esta metodología de trabajo proporciona muchas veces diferencias de espectativas entre dichos usuarios finales y el proveedor del Sistema, ya que dependiendo del tiempo ocupado por las fases intermedias de Diseño y Construcción, los requisitos pueden irse modificando (aunque no debiera), la tecnología evolucionando, e incluso las personas responsables variando. Una mayor implicación del usuario final del Sistema de Información en fases intermedias, o mejor, una existencia de prototipos, aplicaciones alpha y beta o similares mejoraría espectacularmente los ratios de cumplimiento de plazos y calidad.
• La calidad es una tarea paralela a las fases de la metodología Metrica, que cuenta con su propio interfaz, pero que se limita a asegurar el cumplimiento de requisitos, objetivos y tecnología. Sin embargo, la calidad debería incluir aspectos adicionales a las propias fases de desarrollo, como por ejemplo la utilización de estándares de comunicación entre las partes (proveedor, cliente, usuario final), el acceso a la información del proyecto en tiempo real, la generación de prototipos, la utilización de herramientas de gestión de proyecto, etc. En definitiva, las sesiones de trabajo son necesarias siempre, pero existen herramientas que pueden proporcionar una mayor interactividad que una sesión de trabajo, ejemplos son Wikis y listas de distribución.

En definitiva creo que quizás una nueva Metrica v4 o bien una Metrica diferente por tipo de proyecto podría aumentar el resultado final de los mismos, aportando en cada caso una metología más precisa, contando con la experiencia de lo que se ha realizado hasta ahora y contando con las nuevas herramientas que además ahora existen.

Compañero que trabaja en un proyecto de desarrollo, que detecta un problema asociado a un producto open source tan importante como jboss. Inicia un procedimiento de reporte de incidencia, con descripción completa de la misma y posible solución.

La incidencia es atendida, es aceptada por el comité de desarrollo y además se utiliza la solución aportada como solución definitiva de la misma, en la próxima release del producto. ¿Es esto eso que llaman comunidad? ¿Es esto software libre?

Este es el nivel que compañeros como Sergio tienen y que aportan al resto de nuestros proyectos con clientes. Enhorabuena.

Aunque ya hace varios meses que el portal del Ayuntamiento de Lepe se puso en producción, ahora es cuando realmente puede verse en su uso habitual, con la mayoría de los contenidos migrados al nuevo gestor de contenidos y los pequeños defectos detectados hasta ahora solucionados en su mayoría.

Para nosotros, este proyecto ha sido, no sólo un trabajo más en cuanto a la experiencia que teníamos sobre gestión de contenidos web, sino una apuesta tecnológica específica por la tecnología de fondo que presenta, así como un apoyo adicional a la comunidad de desarrollo de software libre, con la que hemos colaborado aportando código específico que se ha liberado bajo licencia GPL.

En concreto, hemos intentado aportar nuestro conocimiento para elaborar el portal del Ayuntamiento de Lepe, incidiendo en los siguientes aspectos:

• Arquitectura de la información, definida conjuntamente con el personal del Ayuntamiento.
• Diseño gráfico, por parte de nuestro equipo de diseño, igualmente con las especificaciones del propio Ayuntamiento. Se ha intentado encontrar un término medio entre un diseño limpio y que pueda contener la información necesaria.
• Accesibilidad, hemos tenido muy en cuenta este aspecto, desarrollando con XHTML 1.0 y CSS conforme a las especificaciones del W3C y hemos validado el nivel AA de especificación 1.0 de la WCAG.
• Compatibilidad, el interfaz está diseñado para ser fácil de utilizar por parte de múltiples navegadores y dispositivos, como PDA y Smartphones.

Como gestor de contenidos se ha utilizado Plone CMS, y como he comentado anteriormente, hemos desarrollado dos módulos que se han liberado con licencia GPL:

• Meteo, utilizado para incorporar información de la Agencia Estatal de Metereología.
• Notifica, un sistema de suscripción de boletines de noticias para los usuarios.

A partir de ahora, intentaremos evolucionar lo existente, y mejorar cualquier error o problema encontrado. Así que como siempre, cualquier comentario al respecto será bienvenido.

Un “problema” de la globalización para las empresas dedicadas al desarrollo software en los países más desarrollados es la existencia de una gran competencia en aquellos otros países con unos costes menores de producción, para una actividad como el desarrollo de software, en la que no es necesario contar con una presencia local en el cliente.

El fenómeno llamado deslocalización, en el que ejemplos como las factorías de desarrollo situadas en India o Argentina son su máxima expresión, no deja de ser un fenómeno que no debe ser visto no ya como un problema de competencia, sino como una oportunidad paramejorar nuestro modelo actual de desarrollo, bastante caduco en muchos “fabricantes” de software y muy desprestigiado entre los propios clientes.

Los modelos que creo que debemos utilizar ahora son bastante más globales, para lo cual, contar con una herramienta que sea la base de una correcta metodología de desarrollo es también algo fundamental. Al hilo de esto, herramientas como oDesk nos permiten pasar a un modelo de desarrollo de software diferente, más colaborativo, más globalizado, más deslocalizado en general.

Si además de estas herramientas, se orienta, y esa es una labor nuestra, de los proveedores de software, a los clientes a entender que un modelo de desarrollo requiere de unas fases concretas, casi en la cual la más importante es la fase inicial de análisis, donde entre otras cosas, se establecen los requisitos que deberá cumplir el sistema de información, base para el resto del proyecto, tanto en calidad como en cumplimiento de plazos, estaremos seguro ante unos mejores resultados finales, sin la necesidad de situar a un equipo de personas con sus perfiles determinados en casa del cliente, simplemente porque es lo que se ha hecho hasta ahora.

En definitiva, esta nueva forma de trabajo, con seguridad permitirá una mayor especialización de los ingenieros involucrados en el trabajo, mejorando así la calidad final del producto y minimizando el tiempo de desarrollo, por lo que si además se cuenta con un gestor de equipos especializado, se tendrá un éxito rotundo, sin tener que estar en un lugar concreto, los equipos colaborativos funciona cuando la cultura de los mismos es así de clara.

Para desarrollar proyectos software (principalmente con tecnología Java), en nuestra empresa nos apoyamos en una infraestructura de desarrollo hecha a medida, de la que posiblemente en poco tiempo tengamos noticias interesantes para mostrar, pero que básicamente se basa en múltiples componentes de software libre integrados entre sí para facilitar la gestión y calidad durante las fases de desarrollo de los sistemas de información, más concretamente durante la fase de implantación.

Una de las principales necesidades que aún no teníamos cubiertas, y que para nosotros era pincipal para demostrar la calidad del software que estamos desarrollando, es la posibilidad de obtener métricas concretas sobre dichos proyectos, métricas que estableciesen el nivel de calidad de los mismos, conforme a los estándares de la industria.

Para ello, nuestro equipo de desarrollo y en especial nuestras personas dedicadas a QA, han estado trabajando para integrar un módulo a dicha infraestructura de desarrollo que nos permitiera obtener dichas métricas de análisis estático, bien explotando los datos que ya teníamos almacenados por parte de otros módulos del sistema o bien generando nuesva información que fuese útil para el objetivo.

Ahora ya tenemos una versión inicial funcionando en nuestra infraestructura de desarrollo, y como ejemplo, podemos obtener los siguientes índices relativos a nuestros proyectos de desarrollo:

• Líneas de código, con el número de paquetes, clases y métodos que existen en las mismas.
• Comentarios, medidos tanto envalor absoluto como en porcentaje respecto al número de líneas de código.
• Cobertura de cógido que recogenlos tests diseñados.
• Porcentaje de acierto en dichos tests.
• Cumplimiento de reglas de codificación.
• Eficiencia.
• Mantenibilidad.
• Portabilidad.
• Fiabilidad.
• Usabilidad.

Además, obtenemos, por cada módulo de los sistemas en desarrollo, una gráfica que recoge en un nivel de color establecido el cumplimiento de las reglas de codificación y de la cobertura de código realizada. Como ejemplo podéis ver en el gráfico el estado actual de uno de nuestros proyectos.

La idea no es quedarnos aquí, sino ampliar la fucnionalidad de este módulo para poder obtener informes períodicos en formato PDF o similar y para aumentar tanto el número de íncides como su presentación gráfica.

De esta manera, no sólo nuestros ingenieros tendrán conocimiento de la calidad de su trabajo, sino que además, nuestros clientes podrán ver también en tiempo real estos datos, pudiendo generar informes de estado, que contribuirán con total seguridad a maximizar la calidad final de nuestros productos. Y por ello, no quiero dejar de dar las gracias a todos mis compañeros que, además de hacer que su trabajo crezca día a día, con seguridad facilitan el mío en el futuro.

He estado últimamente leyendo información sobre Osmius. Tengo que reconocer que aún no lo he visto funcionar, de hecho no he visto ni siquiera su interfaz gráfico (es una de las cosas que creo deberían añadir los chicos de peopleware en su página para hacer más atractivo el producto).

De cualquier forma, tampoco trataba de hablar sobre las cualidades del producto, esto intentaré tratarlo más adelante cuando pueda verlo en funcionamiento. Lo que quería destacar aquí es más bien la segunda parte del título de este post, es decir, Made in Spain.

Aún sigue habiendo diferencias entre los distintos mercados software del mundo, incluido como no el mercado del software libre. En otros países, los proyectos de software libre que existen, o bien pertenecen a un grupo de gente que libremente presta su tiempo y conocimientos a la generación de una idea o producto (hay miles, en Sourceforge pueden encontrarse), o bien pertenecen a una fundación sin ánimo de lucro (Mozilla y su Firefox es el mejor ejemplo), o una empresa (nosotros también hemos hecho algo al respecto) o bien son una forma totalmente legítima de comenzar un plan de negocio (sin ir más lejos, la gente de Magento).

Aquí en España aún es difícil llegar a un modelo de negocio en el cual un grupo de personas comienzan un negocio a través del desarrollo de software libre, que van mejorando con ayuda de la comunidad, pero que lideran convenientemente, para controlar su evolución y para generar alrededor de dicho software servicios o productos que puedan rentabilizar en el futuro (soporte, instalación, consultoría, modificación a medida, etc.). Esta misma semana ponía el ejemplo de eyeOS como software libre que sigue este modelo, pero no suele ser lo habitual.

Aquí, por contra, lo habitual es utilizar recursos de investigación y desarrollo, ya sean del gobierno o de las propias empresas, para comenzar este tipo de proyectos (¿os suena OpenBravo?). Y sin embargo hay gente muy buena trabajando en España, con ideas interesantes, que no pueden iniciar porque no existen las empresas o los business angels que les permitan dedicarse a la misma.

Osmius es de estas últimas, es decir, contando con ayuda estatal para I+D, la gente de peopleware ha sabido interpretar lo que significa un modelo de desarrollo de software libre, añadiendo al mismo componentes de investigación pura (la utilización de inteligencia artificial a la hora de tratar la correlación de los eventos de monitorización del sistema es un ejemplo), y apoyándose en centros de investigación (en este caso una Universidad), para generar además un producto de calidad, hecho aquí mismo. Modelo a seguir.