archivo

Archivos diarios: septiembre 10, 2011

Cualquier gestor que tapa sus oídos y no escucha a los componentes de su equipo de trabajo está dejando pasar muchas oportunidades de mejora.

No importa de quiénes vengan las ideas, no es ninguna deshonra que personas con menos experiencia, conocimientos o que se encuentran a tu cargo aporten soluciones que lo mismo mejoran las que estás aplicando o que le proporciona un añadido que la enriquece o potencia. Diferentes puntos de vista permiten conseguir una mejor perspectiva del problema.

Recoger estas ideas permite además que el equipo se encuentre más integrado en el proyecto porque es una demostración de que todos suman, independientemente de su rol o perfil, y que las opiniones se respetan y se escuchan.

Los requisitos funcionales y no funcionales de un sistema de información determinan el mapa inicial de lo que los usuarios esperan del sistema. Se trata de una predicción sobre lo que que quieren y que después tendrán que constrastar con el producto final.

Lo normal es que exista una diferencia entre una versión de un producto y lo que se esperaba de ella, por lo que después son necesarios mecanismos de ajustes que disminuyan esa distancia a unos umbrales razonables o que la eliminen. Lo ideal es que esa diferencia sea la menor posible y los analistas funcionales y orgánicos y los responsables de codificar el proyecto intenten que así sea, sin embargo los proyectos de desarrollo de software están sometidos a muchos factores que afectan negativamente a ese objetivo.

En cualquier caso, los requisitos representan necesidades y expectativas de los usuarios y es necesario, por tanto, conocerlos y tenerlos en cuenta como referencia en el desarrollo del producto software.

Por tanto, este área de proceso requiere que los requisitos estén perfectamente identificados y, además, sean conocidos y entendidos por todos los implicados en el proyecto (equipo de proyecto, usuarios, responsable técnicos del cliente, etc…).

Otro de los requerimientos de este área es que se tenga control sobre el cambio en los requisitos, para ello es necesario que solo un grupo reducido de personas tengan la capacidad de decidir en ese sentido.

Esto no quiere decir que cualquier usuario no pueda proponer cambios, antes al contrario, cualquier aportación debe ser acogida de forma positiva, el matiz en este caso, es que esas propuestas deben ser analizadas por unos pocos (que se entienden que son designados como expertos del proceso o procesos que se informatizan) y que con el asesoramiento de los técnicos software (sería lo más recomendable) toman la decisión sobre qué cambios realizar, cuáles no y en definitiva, cuáles son las prioridades.

Ante una decisión de cambio en los requisitos, este área de proceso tiene el requerimiento de que el resto de artefactos/entregables del proyecto se mantengan consistentes.

Por este motivo hay que tener mucho cuidado a la hora de definir los entregables documentales de un proyecto, ya que cuántos más y más complejos sean, mayor será el esfuerzo necesario para ponerlos consistentes. Es importante apoyarse en herramientas CASE para facilitar la consecución de este objetivo.

Otro requerimiento es la trazabilidad bidireccional y sobre esto habría mucho que hablar. Si se toma al pie de la letra quiere decir que debería poder conocer todos los componentes de ingeniería del software y del producto software (a nivel de clase) asociados a un requisito y también en el sentido contrario, es decir, que partir de una clase se sepa a qué requisito o requisitos puede afectar un cambio en la misma. El objetivo de esto es poder realizar un análisis de impacto y servir también de soporte para la detección de inconsistencias entre los requisitos y los productos derivados del proyecto (incluido el propio sistema de información).

Sin embargo, esta trazabilidad bidireccional resulta costosa de conseguir y no resultaría aconsejable su aplicación en determinados tipos de proyectos (se estaría matando moscas a cañonazos) y en otros, llegar a nivel de clase en el código no aportaría mucho ya que la organización en capas, de las clases, etc… viene condicionada por el generador de código utilizado y el framework.

Para poder respectar en lo posible este objetivo, es importante definir un nivel de entregables documentales acordes a la naturaleza del proyecto (maś entregables, más complejidad, así que hay que tener cuidado con esto) y tener un conocimiento del framework de desarrollo y de la arquitectura de la aplicación, de manera que se sepa de manera rápida donde hay que mirar para conocer el impacto de la modificación de determinados requisitos (lo que se hace es mirar de más arriba la codificación de la aplicación y no entrar a un detalle a nivel de clase). También resulta fundamental un código lo más claro y limpio posible.

Sobre la trazabilidad lo importante, entiendo que debe ser quedarse con el espíritu de la misma y tener unos procedimientos en el proyecto que permitan hacer un análisis de impacto y análisis de consistencia en un tiempo razonable. Hay que recordar que CMMI establece un modelo de referencia, determina el qué pero no el cómo.

La falta de control sobre los proyectos, equipos de trabajo, calidad del servicio, etc… que de manera generalizada existe en el nivel uno es un reflejo de lo que pasa en, tal vez, demasiadas organizaciones dedicadas al desarrollo de software y que perjudica de manera considerable a los proyectos y en consecuencia al cliente, al proveedor, a los destinatarios finales del servicio y en definitiva al negocio del desarrollo de software, negocio que si seguimos sin cuidar no conseguirá la evolución que requiere para ser considerada una disciplina al nivel de las otras ingenierías.

Los procesos no son solo para empresas grandes también son válidos para entidades de cualquier tamaño. Si nuestra vida diaria está llena de procesos, propios y ajenos, ¿por qué darles de lado en el desarrollo de software?.

Es cierto que cada proyecto de desarrollo de software es distinto ya que siempre cambian algunas de las variables que condicionan el mismo, no obstante, eso no debe ser un obstáculo para intentar implantar procesos, ya sean generales en la organización o propios para el proyecto que permitan tener un cierto control sobre lo que se está haciendo y la posible evolución que puede tener.

Y no es cuestión de que CMMI proponga la implantación de procesos en determinadas áreas que permitan conseguir estos objetivos sino que es cuestión de sentido común. Por tanto, guste o no guste CMMI, se compartan o no sus fundamentos, es evidente que sin una organización real, sin unos mecanismos de gestión adecuados, estamos condenando a los proyectos a una situación en las que los problemas, las crisis, llegarán demasiado tarde a quienes tienen que tomar decisiones, al no existir mecanismos de medición de diferentes métricas objetivo no se tendrá referencia para poder mejorar, etc…

Con esto quiero decir que CMMI recomienda un modelo, que puede ser válido como otros, pero que compartirá con ellos la necesidad de aplicar procesos repetibles, estrategias comunes, en diferentes áreas de la gestión y de los proyectos individuales.

El segundo nivel de CMMI pretende dar un primer paso respecto a la situación de anarquía inicial, en la que no existen procesos o si existen no se aplican o controlan. En este nivel se entiende que para aplicar estrategias de nivel organizativo es necesario crear primero una cultura orientada al proceso y para ello plantea como estrategia que por los menos los mismos se implanten a nivel de proyecto.

Bastará, por tanto, con las procesos se definan a nivel de proyecto, pudiendo ser distintos entre unos y otros. Lo importante es que existan mecanismos de gestión, control y supervisión, que sean distintos entre los diferentes proyectos no es esencial, ya que se habrá conseguido un avance significativo respecto al nivel anterior al existir mecanismos que permiten obtener información del estado del proyecto, de su avance, de sus posibles desviaciones, de los posibles problemas que pueden existir.

Conseguir lo anterior, no es poco y los beneficios son evidentes, pero sobre todo hay uno que considero muy importante y es que por lo menos a nivel de ámbito de proyecto se sepa cómo actuar en cada caso y no tener que estar preguntando cómo se hace esto, como se pide lo otro o un escenario todavía peor en el que cada uno por su cuenta decida qué hacer.

En los próximos artículo sobre la materia se realizará un repaso a los diferentes procesos que se tienen que implantar de manera adecuada para considerar que una organización tiene un nivel dos de madurez.

Si la finalidad última de un sistema de información es satisfacer las expectativas de los usuarios materializada en la informatización de un proceso o de una serie de procesos que permita realizar su trabajo con mayor eficiencia y productividad y/o la organización se beneficie mediante el almacenamiento y automatización de la información que se maneja, sin embargo ¿qué pasa cuando los usuarios no se sienten identificado con el problema o simplemente sienten que no existe un problema?.

Pues pasa que el proyecto para ellos pasa a ser algo secundario, cuando no algo sobre lo que poner todas las trabas posibles con el objeto de que no llegue a ningún sitio. ¿Acaso no conocemos todos proyectos que no han ido a ningún lado? Pues aquí una de las principales causas (junto a una mala ejecución de los mismos).

Por eso soy de la opinión de que no es misión de un departamento TIC de una organización crear necesidades ni en usuarios ni en directivos, sino que las necesidades deben ser expresadas por ellos y una vez hecho eso comprometerse e implicarse en el proyecto desde el principio hasta el final.

Sobre este tema Weinberg realiza una reflexión interesante cuando comenta (traducción libre): “Al final de todo, no hay mucha gente que quiera ver sus problemas resueltos”.