archivo

Archivo de la etiqueta: analista funcional

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).

Si la finalidad de los productos que desarrollamos es que lo utilicen usuarios es un mal síntoma que buena parte del equipo de proyecto esté alejado de los mismos.

Generalmente son los analistas los que tratan con los usuarios, a veces también lo hacen los jefes de proyecto, mientras que el resto del equipo por arriba y por debajo apenas tiene trato con ellos.

En otros modelos orientados a factorías de software, son aún más las capas que separan a los desarrolladores del cliente.

Sobre esto habrá opiniones de todo tipo, pero desde mi punto de vista, cuando los técnicos solo ven papel (o su equivalente en una herramienta CASE) termina por olvidarse para qué y para quién se desarrolla y eso es un problema importante porque nos robotiza en lugar de humanizarnos y nos convertimos en autómatas que ejecutamos trabajo, que anotamos nuestras horas en el sistema de gestión de incurridos que se utilice y que tratamos de no desviarnos de las previsiones que nos han indicado nuestros superiores, en ese contexto, ¿qué margen le queda al usuario?, ¿qué margen le queda a la calidad del producto?.

Este antipatrón recibe el nombre de una canción infantil. Os la pongo tal cual:

Oh, The grand old Duke of York,
He had ten thousand men;
He marched them up to the top of the hill,
And he marched them down again.

And when they were up, they were up,
And when they were down, they were down,
And when they were only half-way up,
They were neither up nor down.

Como podréis ver describe simplemente la acción de subir una colina, para después volverla a bajar. Se considera como una metáfora del esfuerzo invertido de manera gratuita o innecesaria.

No obstante, este antipatrón, aunque en el fondo haga referencia a un esfuerzo de esas características, quiere hacer hincapié sobre todo en una de sus posibles causas.

De igual manera que roles de carácter funcional resultan de mucha utilidad como nexo de unión (que no intermediario) entre usuarios y equipo de proyecto, también es necesario destacar la figura de los arquitectos software y a más bajo nivel los analistas orgánicos.

En el caso de los primeros existe una visión más abstracta del comportamiento funcional del sistema de información y en el de los segundos existe una visión más abstracta de la arquitectura de la aplicación, en ambas situaciones se ve el bosque y no los árboles.

Es frecuente encontrarnos con proyectos donde alguno de los dos perfiles no interviene (cuando no los dos), dejando a los programadores (especialistas en la implementación) prácticamente todas las decisiones a nivel e ejecución de las especificaciones del usuario.

Esto suele provocar (de ahí la analogía con la metáfora de la canción de “El gran viejo Duque de York”) que determinadas decisiones, al tener una visión demasiado a bajo nivel de la aplicación, no busquen la solución más óptima y obligue a hacer esfuerzo de más o incluso a un esfuerzo innecesario.

Por tanto, lo que viene a decir este antipatrón es que equipos de proyecto descompensados entre visiones más abstractas y más concretas pierden productividad.

He insistido en diferentes artículos que gran parte de la suerte del proyecto se juega antes de que comience. Una mala negociación, una mala venta condiciona todo lo demás (pudiéndose partir de una situación de Death March Project) y solo produciéndose determinadas circunstancias ideales: un equipo de proyecto motivado y de calidad y un cliente y unos usuarios que facilitan las tareas, pueden paliar las pérdidas del proyecto, tangibles (en dinero), como intangibles (de pérdida de imagen con el cliente ante un proyecto de ejecución deficiente).

Sin embargo, la venta inicial del producto es solo una de las variables que condicionan el posterior desarrollo del proyecto, la elección de una mala metodología ya sea por parte del proveedor o impuesta por el cliente puede hacer estragos en el trabajo realizado, en el coste y en los resultados.

Lo mismo si no se delimita de manera adecuada el alcance (ya sea antes de la venta o antes incluso de empezar a recoger requisitos).

Y después toca el análisis. Si la metodología condiciona un desarrollo en cascada la realización de un análisis excelente es esencial, si bien, todo se puede ir al traste en el momento en que cambia algunas de las variables del proyecto (interlocutores, procesos, etc…) y es que los modelos predictivos tienen ese problema.

Si la metodología es ágil o al menos iterativa incremental (como RUP), las tareas de análisis también son de gran importancia, aunque desarrollos iterativos y evolutivos dan un mayor margen para la corrección de deficiencias en la captura e interpretación de los requisitos y en el modelado de la solución.

Por tanto, independientemente de que en función de la metodología aplicada la realización de un buen análisis tenga una mayor importancia, en todas condiciona el resto del proyecto y muchísimo.

Un mal análisis, si se detecta en etapas tardías (en muchos casos, cuando el producto ha llegado a producción), provocará un más que probable fracaso de la puesta en marcha del sistema y un más que probable esfuerzo económico importante para resolver esta circunstancia, mediante mantenimientos correctivos y evolutivos, que podrían ser incluso no asumibles si la deuda técnica del desarrollo es elevada.

Pero es que un mal diseño también tiene consecuencias y muy importantes en el resultado final del software.

Por eso destaco siempre que, además de contar con buenos programadores, disponer de buenos analistas funcionales y orgánicos permite que el trabajo de los que codifican brille más y sobre todo, sea útil.

De ahí la importancia de realizar testing desde el principio, fundamento este que dió lugar, por ejemplo a las metodologías de testing en V o en W.

En resumen, aunque muchos piensen que el partido se juega en la construcción del software, si no se han realizado de manera adecuada las etapas anteriores, el partido se habrá perdido antes de que el árbitro de el pitido inicial.

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.

Tanto si vamos a trabajar con metodologías ágiles, como con otras metodologías como RUP y sobre todo, en ciclos de vida clásicos o en cascada, resulta fundamental delimitar cuanto antes el alcance del proyecto.

Como mínimo hay que llegar a una primera aproximación en la negociación del contrato con el cliente (cuanto mejor sea la misma, más variables se tendrán a favor para hacer una correcta valoración en esfuerzo y plazos del proyecto) y es más que recomendable hacer otra aproximación al inicio del proyecto.

Acotar el alcance no debe ser entendido como poner límites al proyecto, al menos en el sentido estricto, ya que a través de la propia evolución del software, la aplicación tenderá a ir hacia donde van las expectativas del usuario. Pero sí se debe entender como un marco hacia donde enfocar el desarrollo, ya que no todas las funcionalidades que se quieren implementar son iguales de prioritarias o críticas.

El proyecto debe centrarse en lo verdaderamente importante, dejando para más adelante aquello que no lo es. Probablemente no habrá presupuesto (por lo menos en primera instancia) para todo, por lo que lo primordial es cubrir lo que resulta necesario.

Si no delimitamos el alcance, se quedarán demasiadas puertas abiertas por detrás, con el riesgo de que el cliente o usuarios quieran volver a ellas. Es cierto que al final el proyecto va hacia donde quiere el cliente o los usuarios, pero no es lo mismo tener pactado por escrito un alcance que no tenerlo y no es lo mismo hacer pedagogía desde el inicio del proyecto que no hacerla.

En el último artículo que publiqué sobre la temática de los casos de uso, un lector me dejó el siguiente enlace (en inglés): Cómo implementar operaciones CRUD en UML, en el que como respuesta se indica que si la representación en los diagramas/modelos no aportaba valor, tal vez la mejor solución pasaba por no representarlos.

Y me parece una buena propuesta, ¿por qué no?, sin embargo sí que soy partidario que cómo mínimo, en el caso de los casos de uso se estereotipen los que se correspondan a gestiones CRUD y que se haga referencia a un guía, libro blanco, etc…, de la organización en la que se especifique cómo debería ser el comportamiento en este caso, en los maestros/detalle o en cualquier otro tipo de figura que se quiera estandarizar.

Los generadores de código suelen resolver la problemática del CRUD, sin embargo, no todos la resuelven de la misma manera. Si existen diversas empresas que desarrollan para tu organización, te encontrarás con que utilizan diversos generadores y la solución de salida será distinta, algo que en la medida de lo posible resulta interesante evitar.