Buscar en Gazafatonario IT

martes, abril 17, 2012

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.

lunes, abril 16, 2012

¡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:
Y este otro:

domingo, abril 15, 2012

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.

sábado, abril 14, 2012

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:

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.

viernes, abril 13, 2012

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.

miércoles, abril 11, 2012

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

lunes, abril 09, 2012

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

domingo, abril 08, 2012

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.