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.

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.

Se acaba de inaugurar la web de JSWEB 2008, jornadas técnicas sobre Servicios Web y arquitecturas orientadas a servicios (SOA), que se han convertido en el referente español en este tipo de tecnologías.

Este año además las jornadas las organiza la Universidad de Sevilla, y nosotros participamos inicialmente como patrocinadores, pero por supuesto estamos más interesados en presentar las ideas que tenemos sobre estas tecnologías y también los proyectos en los que ya hemos participado y en los que se se han utilizado. Sobretodo porque sigue siendo algo incipiente, y el típico “lecciones aprendidas” es fundamental ahora mismo para todo el que piense en utilizarlas.

Se acaba por tanto también de abrir el período de aceptación de contribuciones, que finaliza a finales de julio, por lo que el que está interesado en exponer cualquier tema relacionado con estas tecnologías tiene la oportunidad de contar con el espacio y tiempo necesario para ello, en un foro compuesto por personas especialistas que necesitan conocer cuánto se mueve en este sector.

Más tarde, en septiembre se definirá la agenda al completo, pero no cabe duda que es uno de los foros donde es un delito no estar, y menos aún para nosotros este año.