archivo

Archivos diarios: septiembre 14, 2011

En el anterior artículo sobre CMMI vimos el área de proceso de seguimiento y control del proyecto como consecuencia lógica del área de proceso de planificación del proyecto, ya que si se establece un plan es para realizar un seguimiento del mismo y de las variables que define, de manera que se pueda dar respuesta a posibles desviaciones lo antes posible.

Este área de proceso va más allá de ese seguimiento y control, ya que el mismo está orientado al día a día del proyecto, sino que está más dirigido a la definición de una serie de objetivos del proyecto y de la organización (en los que influye los resultados del proyecto), donde el grado de cumplimiento de los mismos se verifica a través del análisis de las métricas definidas para cada uno de ellos (una o más), para las cuales se tiene que definir la forma en que vamos a recopilar los datos y obtener los últimos.

El fin último de este área de proceso es comunicar los resultados obtenidos a través del análisis de los datos, es decir, medir para tomar decisiones que permitan mejorar.

¿Qué objetivos se pueden definir para el proyecto?

Por ejemplo, conseguir un 70% de cobertura en pruebas unitarias, mejorar la satisfacción del usuario en cada iteración del producto, entregar los hitos en fecha, conseguir que el número de vueltas a atrás tras la entrega de hitos sea menor o igual a uno en el 90% de los casos, que el número de incidencias tras el paso a producción de una versión sea inferior a un umbral determinado, cumplir con determinado tiempo de respuesta ante incidencias, mejorar progresivamente el velocity del equipo de trabajo, acertar un determinado porcentaje de las estimaciones de esfuerzo realizadas, etc…

Hay que tener en cuenta que lo mismo el proyecto se desarrolla bajo un ANS, en estos casos debe condicionar los objetivos del proyecto los cuales deberán tener en cuenta las métricas definidas y como mínimo cumplirlas.

¿Qué objetivos se pueden definir para la organización?

Por ejemplo, incrementar el número de proyectos que se presentan en plazo, mejorar la productividad, mejorar los márgenes de beneficio del proyecto, reducir el número de errores en las entregas, conseguir una satisfacción media de los clientes tras el cierre de cada contrato igual o superior a un 7, etc…

A veces no se tiene claro que objetivos plantear (sobre todo si no hay ANS), no importa, lo importante es empezar tal vez con pocos objetivos pero que sean medibles y nos puedan proporcionar información de interés para el proyecto y para la organización. Siempre habrá tiempo, cuando ya se vaya implantando esta cultura, de incrementar los mismos.

¿Cuántas veces hemos escuchado al usuario comentar qué por qué el sistema le solicita una información que ya se encuentra almacenada en el mismo o por qué no le proporciona información calculada que se podría obtener con los datos ya introducidos?

Quitando aquellos casos en los que el usuario se equivoca (porque realmente el sistema no tiene almacenado los datos que él pensaba) es un problema que se produce en muchas ocasiones y que se traduce en la necesidad de un mantenimiento evolutivo del sistema.

Un buen diseño de modelo de datos es muy importante ya que permite que los datos se almacenen de forma que su posterior recuperación o su utilización para devolver datos calculados sea lo más sencilla posible. Un mal diseño del modelo de datos provocará consultas complejas para obtener aquellos datos o información más utilizados en el sistema.

Pero tan importante resulta tener un buen diseño del modelo como conocerlo de manera adecuada. A lo largo de la vida de un sistema diferentes personas habrán participado en el diseño y si no se conoce de manera adecuada dará lugar a un redundancia de datos, un incremento de la complejidad del modelo, un manejo deficiente de los datos, etc…

Sobre esto hay una cita de Rick Lemmons que viene muy bien para exponer este caso: «No hagas que la interfaz de usuario proporcione información que el sistema ya sabe».