Casos de Uso 2.0 – Aplicable a todos los tipos de sistemas y organizaciones

Casos de Uso 2.0 puede ser usada en muchos contextos distintos para ayudar a producir muchos tipos de software diferentes.

Aplicable para todos los tipos de sistemas: Mucha gente piensa que los casos de uso son solamente aplicables a sistemas usuario-dependientes, es decir, aquellos donde los usuarios hacen uso intensivo de los mismos, donde hay mucha interacción entre usuarios humanos y el sistema. Esto es extraño porque la idea original de los casos de uso vino de los sistemas telecomunicaciones, que tenían tanto usuarios humanos (suscriptores, operadores) como usuarios máquinas, en forma de sistemas interconectados. Los casos de uso son aplicables para todos los sistemas que son usados.

Casos de Uso 2.0: no es solo para aplicaciones de uso intensivo por usuarios

De hecho, muchos casos de uso son útiles para sistemas embebidos con poca o ninguna interacción humana. Actualmente la gente está usando casos de uso en el desarrollo de cualquier clase de software embebido en dominios tan diversos como el la industria del consumo electrónico, del motor, militar, aeroespacial y médica. Aun sistemas de control de procesos en tiempo real usados para plantas químicas pueden describirse mediante casos de uso, donde cada caso de uso se enfoca en una parte específica del comportamiento del proceso de la planta y de las necesidades de automatización.

Casos de Uso 2.0: no es solo para desarrollo de software

La aplicación de casos de uso no está limitada al desarrollo de software. Estos también pueden ser usados para ayudar a entender los requisitos del negocio, analizar el negocio actual, diseñar nuevos y mejores procesos de negocio, y explotar el poder de la IT para transformar el negocio. Usando casos de uso recursivamente para (1) modelar el negocio y sus interacciones con el mundo exterior y (2) modelar los sistemas necesarios para soportar y mejorar el negocio, es posible identificar fácilmente donde el sistema impactará el negocio y cuales sistemas son necesarios para soportar el negocio.

Los casos de uso usados para modelar el negocio son muchas veces referenciados como casos de uso del negocio. Estos proporcionan el contexto para el trabajo de desarrollo de sistemas de la IT, permitiendo que el desarrollo del negocio y el desarrollo de la IT se lleven a cabo de manera sincronizada. No solo es posible desarrollar los sistemas IT porción por porción sino que también es posible desarrollar el modelo del negocio porción por porción. Esto es muy poderoso porque permite evolucionar el negocio y sus sistemas de apoyo en conjunto unos con otros, habilitando el desarrollo incremental del negocio así como el desarrollo incremental de los sistemas.

En el mundo moderno, el negocio y los sistemas de la IT que lo soportan pueden, y deberían, ser desarrollados en sincronización (uno no trabajará sin el otro). El uso de casos de uso y de porciones de casos de uso tanto en el negocio como en la IT puede cerrar la brecha entre el negocio y la IT habilitando el trabajo como socios colaborativos verdaderos.

¡Quiero una Porción de Caso de Uso!

No se trata de una charada ni nada por el estilo. El concepto fundamental de Casos de Uso 2.0 (como fue expuesta por Ivar Jacobson en su eBook “Use Case 2.0 The Definitive Guide”), es el de caso de uso y con este, el de “porción de caso de uso” (Use Case Slide, en inglés).

Ya sabemos ampliamente qué es un caso de uso y que todos los casos de uso de un sistema constituyen todos los posibles caminos que un usuario puede tomar para usar el sistema. Un caso de uso tiene una meta bien establecida, una estructura de historia entendida por todos los involucrados en el proyecto, pero también un conjunto de historias que el sistema debe satisfacer o cumplir, incluyendo la más simple, la cual es la historia más simple que le permite al usuario alcanzar la meta.

Y todo esto se puede lograr implementando cada caso de uso porción por porción. Así que ¿qué es una porción de caso de uso? Una porción de caso de uso es una o más historias seleccionadas de un caso de uso para formar un elemento de trabajo que es de valor claro para el usuario. La porción actúa como un contenedor para todo el trabajo requerido para completar la implementación de las historias seleccionadas. Las porciones de casos de uso son más que requisitos y casos de prueba y evolucionan para incluir las porciones correspondientes a través del diseño, la implementación y las pruebas.

La porción de caso de uso es la parte más importante de Casos de Uso 2.0 y no es solamente usada para ayudar con los requisitos sino también para conducir el desarrollo de un sistema que los solucione. Las porciones de caso de uso:

·         Posibilitan que los casos de uso sean divididos en unidades de trabajo más pequeñas e independientemente entregables.

·         Posibilitan que los requisitos contenidos en un conjunto de casos de uso sean ordenados, priorizados y tratados en paralelo.

·         Enlazan los distintos modelos de un sistema (requisitos, análisis, diseño, implementación y pruebas) usados en el desarrollo dirigido por casos de uso.

Por ejemplo, en un caso de uso cuyo propósito es que un cliente de un banco retire dinero vía cajeros electrónicos (ATM), una porción básica del caso de uso es aquella en la que el cliente inserta su tarjeta débito, proporciona los datos de su pin y la cantidad a retirar y la máquina le entrega la cantidad solicitada. Otra porción puede ser aquella en la que el pin no concuerda con los datos de la tarjeta, otra porción es cuando el cliente no tiene fondos suficientes, otra es cuando el cliente ingresa varias veces el pin de manera incorrecta y el sistema bloquea la tarjeta. Y así, puede haber muchas porciones de caso de uso en un caso de uso relativamente simple.

Así que ¿de qué sabor quieres tu porción de caso de uso?

PD. Sobre casos de uso, los invito a leer las Lecturas Fundamentales de este Gazafatonario IT. http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html.

Sobre casos de uso 2.0, pueden ver mi artículo en:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20.html

Y este otro:

http://gazafatonarioit.blogspot.com/2012/04/casos-de-uso-20-y-metodos-agiles.html

Todavía Otro Cuerpo de Conocimiento Más (BABOK 2.0)

El Business Analysis Body of Knowledge (BABOK) es una colección de conocimiento dentro de la profesión del Análisis de Negocio y refleja unas mejores prácticas generalmente aceptadas. Como con otras profesiones, el cuerpo de conocimiento es definido y mejorado por profesionales Analistas de Negocios quienes lo aplican en su trabajo diario. El BABOK  describe las áreas de conocimiento del Análisis de Negocio, sus actividades asociadas y las tareas y habilidades necesarias para ser efectivo en su ejecución.

Como todo cuerpo de conocimiento (PMBOK, SWEBOK, entre otros), el BABOK tiene varias áreas de Conocimiento. Cada una de estas áreas se enfoca en una parte del análisis del negocio. Estas áreas son:

·         Planeación y Monitoreo del Análisis de Negocio

·         Obtención de Requisitos

·         Gestión y Comunicación de Requisitos

·         Análisis Empresarial

·         Análisis de Requisitos

·         Evaluación y Validación de la Solución

·         Competencias Subyacentes 

·         Dinámica de Análisis de Negocios 

Me parece importante anotar que esto no es más que eso, una propuesta de prácticas que funcionan en ciertos contextos, en muchos realmente, pero no es una solución definitiva a todos los posibles escenarios que nos encontramos en la “vida real” del análisis y modelado de negocios en los proyectos actuales.

Cuando se trata de estándares siempre recomiendo darles el beneficio de la duda. Lo primero que debemos hacer es estudiarlo profusamente y entenderlo, apoyándonos en expertos que lo hayan puesto en prácticas en diversas situaciones. A partir de allí, podemos iniciar un proceso de adopción y adaptación. A esto último yo lo llamo “tropicalización”.

Lo adaptamos a nuestras necesidades, a nuestra forma de hacer las cosas, a nuestro presupuesto y economía, a nuestra experiencia (que siempre nos va a faltar), a nuestra idiosincrasia, a nuestra forma de ver el mundo y de interpretarlo, a la agenda tan apretada que tenemos en los proyectos. Esto es importante, porque este tipo de estándares son definidos por organizaciones o grupos de organizaciones que tienen otra filosofía, existen en otras economías (generalmente mejores que las nuestras), la gente que los práctica allá piensa diferente, los proyectos tienen otros presupuestos y otras agendas, los equipos de trabajo son más grandes, tienen más recursos y más experiencia, tienen más expertos, etc.

¿A quiénes les interesa este estándar?

Principalmente a los Analistas del Negocio, pero también a los Ingenieros de Requisitos o Analistas de Requisitos.

“El Analista de Negocios es el responsable de identificar las necesidades de negocios de sus clientes y usuarios interesándose en ayudarlos a determinar las soluciones a sus problemas”.

·         El Analista de Negocios es responsable del:

o    Desarrollo y Administración de Requisitos de sistemas

o    Validación de requisitos para re-ingeniería de Procesos

o    Análisis y recomendación de soluciones de mejora continua

o    Validación y documentación de problemas y oportunidades de negocio

o    Análisis de requisitos Organizacionales u Operacionales

·         Las Soluciones NO son predeterminadas por el Analista- de Negocios- y son manejadas solamente a través del requerimiento de negocios.

·         Las Soluciones frecuentemente incluyen componentes de desarrollo de sistemas- pero pueden también consistir en mejoramiento de procesos o cambios organizacionales.

·         El Analista de Negocios es el facilitador clave dentro de una organización, el cual actúa como puente entre el cliente, el usuario interesado y el equipo de solución.

·         El Análisis de Negocios es distinto al análisis financiero, a la administración de proyectos, al aseguramiento de calidad, al desarrollo organizacional, a la ejecución de pruebas, a la capacitación y al desarrollo de documentación.

Sin embargo dependiendo de la organización, un Analista de Negocios puede ejecutar alguna o todas estas funciones relacionadas.

Estándares Relacionados

Relacionado estrechamente con el BABOK encontramos el SWEBOK (Software Engineering Book of Knowledge), sobre todo en el capítulo 2 que tiene que ver con Ingeniería de Requisitos. Este estándar es soportado por la IEEE.

Analista del Negocio versus Analista Funcional, Parte 2

Veamos ahora el asunto con el Analista Funcional. Este es también conocido como Analista del Sistema, Analista del Software o también Ingeniero de Requisitos.

En términos simples, este personaje es quien identifica (captura), documenta, organiza y administra los requisitos del sistema de software. Más exactamente, es quien desarrolla la Visión del Sistema, atiende las solicitudes de todos los involucrados, define el contexto del sistema, encuentra actores y casos de uso del sistema y estructura el modelo de casos de uso; también es quien desarrolla las especificaciones suplementarias (requisitos no funcionales y otros) y administra las dependencias entre los requisitos.

Este Analista Funcional es quien tiene la tarea de definir el producto que luego usarán los usuarios para resolver sus necesidades de negocio, como se la expresaron al Analista del Negocio. ¿Ah, ya vieron la relación?

Siendo consecuentes con la definición que hice de Analista del Negocio, es recomendable que un analista funcional sea, entre todo lo demás, un experto en la identificación y entendimiento de problemas y oportunidades. Esto incluye la habilidad de articular las necesidades que están asociadas con el problema clave a ser resuelto u oportunidad a ser abordada. A esto yo lo llamo, conocer el problema detrás del problema.

Por supuesto, un buen analista del sistema es un buen facilitador y también debe tener excelentes habilidades de comunicación (todo tipo de comunicación). El conocimiento del dominio del negocio y de la tecnología son habilidades adicionales útiles para estas personalidades. Sin embargo, estas últimas son de menos importancia si el individuo tiene la habilidad de absorber y entender información nueva rápidamente. Y ya que es un papel central en los equipos de proyectos, un analista funcional debe ser capaz de colaborar efectivamente con otros miembros del equipo.

¿Y todo esto qué nos dice? Que siempre es posible que un Analista Funcional o Ingeniero de Requisitos juegue a ser Analista del Negocio; y al contrario, un Analista del Negocio puede ser un analista funcional, aunque esto último no siempre es posible, ya que un Analista del Negocio puede ser “interpretado” por alguien que no tenga preparación académica ni experiencia en tecnología de software y relacionados. Al menos, eso me lo ha enseñado la experiencia. Con el tiempo, ambos roles se pueden intercambiar uno con otro, yo lo he hecho durante la última década sin problemas.

También ocurre que en proyectos de medianos a grandes y dependiendo del presupuesto del proyecto y de la organización, es posible tener los dos roles por separado; pero la mayoría de las veces estos dos roles son jugados por una sola persona. Si son dos personas distintas, deben trabajar en estrecha relación, apoyándose mutuamente y comunicándose todo el tiempo. Este es el factor de clave éxito: la comunicación. No en vano, la recomendación de que ambos figurantes tengan esta como una de sus destrezas esenciales.

----------------------------------------------------------------------------------------------

La primera parte de este artículo lo encuentran en este mismo blog en:

http://gazafatonarioit.blogspot.com/2012/04/analista-del-negocio-versus-analista.html

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.