Analista del Negocio versus Analista Funcional, Parte 1

Hagamos esto en dos partes. En esta hablaré del Analista del Negocio. Empecemos con las definiciones del mismo BABOK.

Un Analista del Negocio  es cualquier persona que ejecute actividades de análisis del negocio, sin importar cual sea su cargo o rol en la organización. Los Analistas del Negocio incluyen no solo personas con ese cargo, sino también analistas de sistemas de negocios, analistas de sistemas, ingenieros de requisitos, analistas de procesos, gerentes de producto, propietarios de producto, analistas corporativos, arquitectos del negocio, consultores de administración o cualquier otra persona que ejecute las tareas descritas en la guía del BABOK, incluyendo aquellas que ejecutan disciplinas relacionadas como gerencia de proyectos, desarrollo de software, aseguramiento de la calidad y diseño de interacción.

¡A decir verdad, todo eso me parece un chiste! Veamos algo más práctico y basado en hechos reales.

Como lo conocemos en este lado del continente, hablo de América Latina principalmente, un analista del negocio es quien lidera y coordina todo el proceso de identificación, documentación, organización y administración de requisitos del negocio delimitando la organización que está siendo modelada. Esto es, un conocedor de los procesos del negocio, alguien capaz de ejecutar tareas como:

1.    Evaluar la organización objetivo, es decir, hacia dónde va la compañía;

2.    Establecer y ajustar objetivos;

3.    Mantener las reglas del negocio;

4.    Identificar las metas del negocio;

5.    Encontrar a los actores y casos de uso del negocio (las actividades del negocio y quien las realiza).

Es recomendable que un analista del negocio sea un buen facilitador y tenga excelentes habilidades de comunicación; además, tener conocimiento del dominio del negocio es esencial para actuar en este papel. UN analista del negocio debe estar preparado además para:

1.    Entender los requisitos de los usuarios, sus estrategias y sus metas;

2.    Realizar un análisis costo beneficio para cualquier cambio que se sugiera en la organización; y

3.    Discutir y apoyar a quienes mercadean y venden el producto final del proyecto.

Adicionalmente, un buen analista del negocio:

1.    Hace análisis arquitectónico del negocio;

2.    Construye pruebas de concepto arquitectónicas para el negocio;

3.    Hace análisis de los casos de uso del negocio;

4.    Prioriza los casos de uso del negocio;

5.    Analiza la operación del negocio; y

6.    Diseña la operación del negocio

Más adelante volveremos sobre este tema para ver quien puede actuar bien en este papel de Analista del Negocio.

Sobre el Papel del Analista Funcional y la Reunión de Presentación de Casos de Uso

Sobre el Analista Funcional

Uno de los errores más comunes que se comenten a la hora de hacer análisis funcional es pensar solo en el presente, en resolver la situación actual, cuando se debería pensar en el futuro, hacía donde quiere ir la organización, cuál es su misión, cuál es su visión y con qué cuenta para llegar hasta allá.

De nada sirve resolver el problema presente si al día siguiente se nos van a presentar otros. En este caso, la anticipación es la clave y más que ello, la visión que tengan los analistas funcionales de hacia donde se va a mover el mercado, el conocimiento de las tendencias, los movimientos de la competencia, las expectativas de los clientes, las corrientes tecnológicas, los rumbos de la economía, entre otros aspectos significativos.

Es allí donde precisamente los indicadores de gestión juegan un papel de apoyo a la hora de tomar las mejores decisiones, aquellas que permitan ir en la dirección correcta. Esa es la trascendencia del Analista Funcional, muchas veces poco vislumbrada en nuestro ámbito, pero real y necesaria. No se trata solo de un asunto de modelamiento de requisitos, se trata de modelar toda una organización y de su perspectiva de supervivencia en el tiempo y en el medio ambiente que la rodea.

Sobre la Reunión de Presentación de Requisitos

Es altamente recomendable que los participantes de la reunión también sirvan como “revisores pares”. Es decir, todos debemos contribuir a que el producto resulte de la mejor calidad posible y esta es una muy buena oportunidad para hacer una gran intervención.

Cada participante bien podría “correr” una lista de chequeo similar, para que la revisión sea lo menos subjetiva posible y para que haya cierta homogeneidad. Esta revisión debería buscar errores de forma, apuntar en principio a aquellos atributos que mencioné en la presentación inicial de este debate, como la claridad, la atomicidad y la precisión de los requisitos y casos de uso, entre otros atributos. 

Pero también, si es posible, buscar errores de contenido, del “negocio”, aspectos que bien pudieron omitirse por parte del Analista Funcional, quizás por considerarlos sobrentendidos o quizás porque nadie se percató de ello con anterioridad. Por ejemplo, revisar si faltaron aspectos contables o regulaciones legales por especificar, o si no se consideraron a ciertos interesados (léase “stakeholders”) externos, como agencias auditoras o supervisoras del gobierno. 

Para todo esto sirve esta primera presentación al resto del equipo y por ello es que la lectura por parte de todos es ineludible.

Sobre “interpretación” vs. “realización” de casos de uso

Algo que ocurre muchas veces es que todos los miembros en un equipo de proyecto de software esperan que en la documentación de requisitos, en general, y de casos de uso, en particular, esté incluido no solo la especificación de requisitos (funcionales y no funcionales), la definición del problema y sus detalles, sino también la solución de ese problema en términos de software.

Es decir, esperamos que la especificación de un caso de uso, por ejemplo, contenga los elementos básicos de un caso de uso, como el Actor, la secuencia básica y las alternativas (si existen), las pre y pos-condiciones y los requisitos especiales, entre otras. Pero también esperamos que tenga la así llamada “realización del caso de uso”. 

Esta no es más que el análisis y diseño del caso de uso, o sea, la manera como se va a implementar ese caso de uso en términos de diseño. Normalmente para esto usamos diagramas de UML, los que sean necesarios, empezando por diagramas de interacción (ya sean de Secuencia o de Comunicación), y también diagramas de Estado o de Actividad, entre otros.

El asunto es que la especificación del caso de uso debe ser lo suficientemente clara (no ambigua) y completa para que cualquier “interpretación” que se haga de la misma arroje los mismos resultados. Y esto debe ser así no solo para el equipo de diseño y de programación, sino para el equipo de pruebas. Es decir, la documentación debe ser tal que el diseñador y el verificador se hagan el mismo modelo o esquema mental del diseño y de las pruebas (casos de prueba) respectivamente.

Algunas técnicas para mejorar la especificación de requisitos (y de casos de uso) incluyen la revisión par, que debe comprender revisión de forma y de contenido. Esta revisión debe validar que cada requisito (y cada caso de uso) cumpla con algunas características bien conocidas:

• Claro
• Atómico
• No ambiguo
• Verificable
• Necesario
• Priorizado

Entre tanto, la especificación de requisitos (incluyendo todos los casos de uso) debe ser:

• Correcta
• Independiente de diseño
• Completa
• Consistente
• Rastreable
• Modificable / Extensible

Para finalizar, los Analistas Funcionales deben presentar esta especificación al equipo de diseño, construcción y pruebas. Este es un paso muy importante que muchas veces se omite o se cumple con simplemente enviar un mensaje electrónico que incluye los documentos relacionados. El objetivo de la presentación no debe ser únicamente exhibir la especificación, sino lograr que todos los involucrados en el equipo salgan con las mismas ideas, con el mismo mapa mental del que hablaba antes.

*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /*+*+*+ /
PD. Los invito a leer mi artículo sobre Realización de Casos de Uso. Lo encuentran en el enlace adjunto: http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html

Casos de Uso 2.0 y Métodos Ágiles

Quienes ven un sabor “ágil” en la práctica Casos de Uso 2.0, como la expone Jacobson, no se equivocan. Esta es una práctica escalable y ágil que puede ser usada junto a prácticas administrativas y técnicas seleccionadas para apoyar el desarrollo exitoso de software y otras formas de sistemas. Su primera característica es que es una práctica liviana y fácil de usar. De hecho, los autores comienzan diciendo que la guía (se refieren al eBook Use Case 2.0 - Guía Definitiva), describe como aplicar casos de uso de una manera “ágil” y escalable. Y estos dos conceptos se extienden a lo largo de cada una de las páginas del documento.

El concepto de “incrementos” y de “historias de usuario”, generalizado en toda la práctica, es inherente a los métodos ágiles como Scrum. De hecho Casos de Uso 2.0 hace referencia a técnicas como el de “Backlog del producto” también usada en los Sprints o iteraciones de Scrum. el backlog (Product Backlog en Scrum) se crea con casos de uso, historias de usuario y porciones de casos de uso, o una combinación de todas estas.

Pero también es importante aclarar que esta técnica no es una franquicia solo para estrategias ágiles. También puede ser usada con otros métodos o procesos como RUP o MSF. La práctica “no es solo aplicable a pequeños equipos ágiles ubicados en una misma oficina, sino que también es para grandes equipos distribuidos que desarrollan de multi-sistemas complejos.” 

Para precisar mi punto quiero referirme al “principio 5: Entregar el sistema en incrementos”, del que habla la guía en el primer capítulo.

En este apartado, los metodólogos enfatizan que “la mayoría de los sistemas de software evolucionan a través de muchas generaciones. Estos no son producidos de una sola vez, sino que son construidos como una serie de versiones, cada una de las cuales es implementada sobre la anterior. Aun las versiones mismas no son producidas de un solo tirón, sino que evolucionan a través de una serie de incrementos. Cada incremento arroja una versión demostrable o usable del sistema. Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. Esta es la forma en que todos los sistemas deberían ser producidos.”

Más adelante remarcan: “Las porciones de casos de uso son una herramienta fabulosa para construir incrementos más pequeños en forma de una versión completa. Esta herramienta permite apuntar independientemente a porciones implementables y verificables de los incrementos, asegurando que cada incremento sea más grande que, y esté construido sobre, el anterior.” El concepto es a todas luces aplicable tanto a los métodos ágiles como a los no ágiles.

PD. Para quienes entran tarde a la sintonía, estoy extendiendo el tema de Casos de Uso 2.0, que inicié hace algunos días en otra entrada. Lo pueden encontrar en http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html

Casos de Uso 2.0

Recientemente, Ivar Jacobson, junto a Ian Spence y a Kurt Bittner, publicó el eBook "Use Case 2.0", sobre las buenas prácticas alrededor del uso de los casos de uso.

Lo primero que debemos decir es precisamente eso: Casos de Uso 2.0 se trata de una práctica para capturar requisitos y guiar la construcción del software. El corazón de esta técnica es, por supuesto, el caso de uso, tal y como lo conocemos. Y también las Historias de Usuario. Y más que el caso de uso o la historia de usuario, la esencia es la “porción del caso de uso” que, como su nombre lo indica, es apenas una parte cardinal del caso de uso. En palabras de los autores, “una porción de caso de uso no necesariamente contiene un flujo completo” y mucho menos un caso de uso completo. Es más bien una parte de funcionalidad con valor para el usuario y que puede servir para la versión o incremento actual del software.

Precisamente, otro concepto importante de esta técnica es la evolución incremental del producto, derivado directamente del concepto anterior. En general, “el sistema debería ser construido por partes, donde cada una de las cuales tenga un valor claro para sus usuarios”.

Según el Dr. Jacobson y compañía, la receta es sencilla: primero se identifica la función más útil que el sistema debe hacer y nos enfocamos en ello. Este es el principio de “enfocarse en el valor”. Luego tomamos esa función más útil y la dividimos en porciones más pequeñas. Y después seleccionamos la porción más importante, una que “viaje” a través de todo el concepto de principio a fin, o lo más cercano que se pueda. Con el equipo de trabajo, estimamos el desarrollo y comenzamos a construir. Luego adicionamos los casos de prueba previamente definidos para esa porción y ya está.

Ahora repetimos eso mismo mientras haya más porciones y más casos de uso que dividir. Así, el sistema lo vamos entregando por incrementos* (principio 5). “Cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. Esta es la forma en que todos los sistemas deberían ser producidos.”

En breve, Casos de Uso 2.0 es una práctica liviana, escalable, versátil y fácil de usar, producto de muchos años de experiencia no solo de los autores sino de la comunidad del software en general. El documento comienza presentando los principios básicos o “Primeros Principios”:

1. Mantenerlo simple contando historias
2. Entender el cuadro completo
3. Enfocarse en el valor
4. Construir el sistema por partes
5. Entregar el sistema en incrementos
6. Adaptarse para cubrir las necesidades del equipo

Y luego se enfoca en el contenido de la práctica en sí (cosas con las cuales trabajar, artefactos de trabajo o productos, y cosas por hacer). También presenta de manera sucinta como debemos usar esta técnica. En este apartado, nos dicen que Casos de Uso 2.0 es para todo tipo de sistemas; que es para manejar todo tipo de requisitos, incluyendo los no funcionales; que puede aplicarse con cualquier estrategia de desarrollo o método; y que la podemos escalar para cubrir todas nuestras necesidades en materia de desarrollo de software.

¿Panacea? ¿Solución definitiva? ¿Bala de plata? Todavía no sabemos. Como dije antes, Casos de Uso 2.0 no es algo totalmente novedoso – aunque sí introduce algunos conceptos poco explorados –, sino que reúne los mejores hábitos en materia de captura, documentación, clasificación y administración de requisitos con casos de uso, y de desarrollo de proyectos de software iterativos e incrementales*.

¿Comentarios?

Salud@s,

Lucho

*Sobre este asunto los invito a leer mi artículo "Gerencia de Proyectos Iterativos" en la revista de la Asociación Española de Profesionales en Dirección de Proyectos.

El artículo lo encuentran en en enlace adjunto.

También pueden bajar la revista completa en http://aepdp.es/project-management-iberoamericano.