Casos de Uso 2.0

No hace mucho, Ivar Jacobson, junto a Ian Spence y a Kurt Bittner, publicó el eBook "Use Case 2.0", sobre cómo mejorar el uso de los casos de uso.

Casos de Uso 2.0 se trata de una práctica para capturar requisitos y guiar la construcción del software.

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.

Todo esto se puede conseguir a partir del concepto que nos presenta Jacobson, la porción del caso de uso, que 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.

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.

Según Jacobson, la receta es sencilla: primero se identifica la función más útil que el sistema debe hacer y nos enfocamos en ello. 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" de principio a fin a través del proceso de desarrollo. Con el equipo de trabajo, estimamos el desarrollo y comenzamos a construir. Luego añadimos los casos de prueba previamente definidos para esa porción.

Ahora repetimos esto mismo mientras haya más porciones y más casos de uso que dividir. Así, el sistema lo vamos entregando por incrementos, "cada incremento se construye sobre el incremento previo para adicionar más funcionalidad o mejorar la calidad de lo que se ha hecho antes. 

Casos de Uso 2.0 es una práctica liviana, escalable, versátil y fácil de usar. El documento comienza presentando los principios básicos:

1. Mantenerlo simple contando historias

1. Entender el cuadro completo

1. Enfocarse en el valor

1. Construir el sistema por partes

1. Entregar el sistema en incrementos

1. Adaptarse para cubrir las necesidades del equipo.

Casos de Uso 2.0 es para todo tipo de sistemas; es para manejar todo tipo de requisitos,  incluyendo los no funcionales; puede aplicarse con cualquier estrategia de desarrollo o método; se puede escalar para cubrir todas nuestras necesidades en materia de desarrollo de software.

¿Demasiada documentación?

Si hacemos esta pregunta a casi todos los stakeholders de un proyecto seguro que nos contestan que sí, que hay demasiados entregables y que esto retrasa las fechas del proyecto. He dicho "a casi todos" porque seguro que al equipo de metodología del proyecto no le parecerán demasiados.
La realidad es que los entregables debe ser algo que debería fijar el propio cliente. Dentro de la ingeniería de Requisitos, los Requisitos Organizacionales forman parte de los Requisitos No Funcionales, y describen aspectos como:

• Procesos estándar utilizados.
• Fechas de entrega.
• Documentación a entregar. Una subcategoría definida como Requisitos de Entrega.
• etc.,.

Nosotros podemos (y debemos) ayudar al cliente a identificar sus necesidades, pero debemos llegar a un consenso en los entregables que debe recibir. Le debemos recordar que los entregables forman parte de su propia necesidad como dueño del producto software. No se hacen porque los desarrolladores quieran sino porque el cliente lo necesita como parte del producto.
Por supuesto, nuestra obligación también es intentar encontrar un nivel de documentación que no sea excesivo pero sí suficiente.

La documentación en el desarrollo de software

A menudo nos encontramos con los siguientes problemas:

• Falta de documentación.
• Exceso de documentación.
• La persona que ha escrito la documentación no está disponible.
• Contenido erróneo de documentación.
• Documentación desactualizada.
• La documentación no sigue el formato establecido según las normas de calidad.
• No contiene control de cambios.
• La documentación se contradice.
• No hay una norma establecida para la gestión de la documentación.
• La documentación no tiene las referencias ni fuentes que corresponden.
• Cada equipo de trabajo gestiona de forma diferente la documentación.
• La documentación fue elaborada con un software que ya no tenemos.

Debemos realizar una documentación de calidad. Debe ser un instrumento que sirva como herramienta para un desarrollo debiendo estar ajustada a las posibilidades y contexto del proyecto.

La documentación debe ser la precisa, ni más ni menos y por ese motivo debe ser el proyecto el que determine la que resulta necesaria.

Debemos distinguir entre varios tipos de documentación a la hora de elegir el tipo y la profundidad de la documentación:

• La documentación que se utiliza a lo largo del desarrollo del proyecto pero que no forma parte de la versión definitiva del producto software.
• La documentación que se utiliza como contrato con el cliente de lo que se va a realizar en el proyecto.
• La documentación que forma parte de los entregables del proyecto.

Respecto del formalismo en la documentación, aunque se puede ser flexible es importante que se siga homogeneidad. Se puede partir de un conjunto de plantillas estándar y negociarlas con el cliente con el fin de que se encuentre cómodo con lo que recibirá.

Una documentación de alta calidad no es el resultado de los formalismos que se establezcan sobre la misma sino por la adecuación de sus contenidos a los propósitos del proyecto. Tener una documentación de un proyecto perfecta a nivel formal no asegura que el producto final satisfaga las expectativas que se tenían puestas en él, lo único que asegura es la inversión de un esfuerzo que se podría haber utilizado para entregar un producto más depurado.

Publicado con Blogsy

El IIBA y el Análisis de Negocio

Os describo qué es y para qué sirve el IIBA

IIBA y Análisis de Negocio

La comunidad internacional de profesionales que se dedican a la definición y especificación de requerimientos decidió crear el International Institute of Business Analysis (IIBA) con el fin de definir las mejores prácticas para esta función.

Gracias a esta organización, se definieron las etapas, tareas, entregables y técnicas necesarias para ejecutar esta función, las cuales al ser adoptadas por una organización y por los practicantes de análisis de negocios en la organización, se mejora sustancialmente el rendimento de esta función ya que su objetivo principal es asegurar que el producto resultado del proyecto, esté construido de acuerdo a los requerimientos de los usuarios, que esté construido de forma correcta y que satisface las necesidades de la organización.

Las organizaciones de alguna manera se han dado cuenta del problema e incluso han creado áreas dentro de la organización para cubrir esta función, las han llamado de diversas formas: Analistas de Sistemas, Business Partners, Business Representatives, Embajadores, Ingenieros de Procesos, Analistas de Negocios, Arquitectos de Negocios, etc., etc. etc., sin embargo no saben qué es lo que estas personas deben de saber para ejecutar la función, o cuales son las mejores prácticas que tanto la organización como los profesionales que ejecutan la función deben de incorporar para realizar esta tarea de manera eficiente.

El Análisis de Negocios es la visión ampliada de la recolección de requerimientos. Uno de sus principios básicos es cambiar la mentalidad del analista de negocios de que no es un “tomador de pedidos”, si no que se convierte en un profesional con los conocimientos (técnicos y de negocios) y competencias (técnicas) necesarias para entender problemas de negocios y proponer soluciones a estos problemas. Su función no es sólo proponer soluciones de TI, sino proponer la solución que requiere la organización haciendo uso de los recursos de la misma esto es, una solución puede abarcar tanto los sistemas de una organización como los procesos o la estructura organizacional. El Analista de Negocios es capaz de proponer soluciones en cualquiera de estos ejes dentro de una organización.

En concreto, el Análisis de Negocios es acerca de entender un problema de negocios, proponer alternativas de solución y definir el alcance de la solución seleccionada considerando todos los recursos de la organización.

Creo que esto es un paso más allá de lo que entendemos como Analistas Funcionales dentro de nuestra organización, pero ¿porqué no podemos conseguir que se dé ese paso?

IIBA, CBAP y BABOK

Podemos equiparar IIBA al PMI, la certificación CBAP a la PMP y el libro BABOK al PMBOK.

Métodos para Análisis Funcional

El objetivo del análisis funcional es describir las funcionalidades del sistema mediante modelos o documentos de análisis. Identifica las interacciones con elementos externos y documenta las estructuras de información necesarias para completar el sistema.

Su papel en el desarrollo de la aplicación es fundamental:

• Servirá de contrato con el cliente.
• Permitirá explicar a nuestros desarrolladores qué funcionalidades tendremos que implementar.
• Nos permitirá estimar el esfuerzo que tendremos que realizar para obtener la solución.
• Podremos plantear qué pruebas tendremos que hacer para comprobar que lo que hemos hecho es lo que el cliente quiere.
• Cuando se acabe el desarrollo nos servirá para garantizar que nuestros equipos de mantenimiento conozcan la funcionalidad de la aplicación, con lo que los evolutivos o correctivos no serán traumáticos.

Un aspecto muy importante y que no debemos olvidar es que aunque el Análisis Funcional es una fase dentro del ciclo de vida del desarrollo, el papel del analista no finaliza cuando acaba la fase de análisis y entrega los artefactos de análisis que ha realizado (p.ej.: el documento de Análisis Funcional). Todo lo contrario, a partir de ese momento su objetivo debe ser que todas las personas involucradas en el desarrollo entiendan e implementen las funcionalidades planteadas.

Normalmente utilizamos uno de los métodos más extendidos en la ingeniería del software para realizar el análisis funcional, los Casos de Uso. Intentaré clarificar una serie de aspectos fundamentales, apoyándonos en ejemplos reales de buenas prácticas.

Además, propondrés técnicas de análisis que seguro en algún momento nos pueden servir para explicar detalles de nuestra solución.

 Nuestra labor como analistas no es hacer unos casos de uso con mucha literatura y super bien estructurados que solo entendamos nosotros. Nuestro objetivo debe ser hacer casos de uso que entienda el cliente y que se ajusten a lo que quiere, que entienda el desarrollador y que le permita realizar su código, que nos sirvan para estimar y que nos sirva para certificar que el sistema cumple con lo que el cliente necesita.

Razones para usar el Modelo de Casos de Uso

Existe mucha controversia sobre el uso del Modelo de casos de uso como especificación funcional del desarrollo de una aplicación. A continuación daré una serie de razones para utilizarlo:

El usuario final aprueba el modelo de caso de uso para saber como va a actuar el sistema. Los usuarios potenciales utilizan el modelo de caso de uso para comprender mejor el sistema. El arquitecto de software utiliza el modelo de caso de uso para identificar la funcionalidad arquitectónicamente significativa. Los diseñadores utilizan el modelo de caso de uso para obtener una visión general del sistema. El gestor utiliza el modelo de caso de uso para planificar y hacer el seguimiento del modelado de caso de uso y también del diseño posterior. Las personas externas al proyecto pero dentro de la organización (ejecutivos, etc.), utilizan el modelo de caso de uso para obtener una perspectiva de lo que se ha llevado a cabo. Las personas revisan el modelo de caso de uso para proporcionar la información de retorno apropiada a los desarrolladores de forma regular. Los diseñadores utilizan el modelo de caso de uso como base para su trabajo. Los verificadores utilizan el modelo de caso de uso para planear las actividades de prueba (prueba de caso de uso y de integración) tan pronto como sea posible. Quienes desarrollarán la versión siguiente del sistema utilizan el modelo de caso de uso para comprender como funciona la versión existente. Los escritores de documentación utilizan los casos de uso como base para escribir los manuales de usuario del sistema.

 

Publicado con Blogsy

Ejemplo de Identificación de Servicios Funcionales

Ejemplo de Identificación de Servicios Funcionales en una aplicación de Seguros

Un ejemplo muy simplificado, que define la funcionalidad necesaria para realizar una consulta de Póliza, una consulta de Siniestros y una consulta de Recibos.

Funcionalidad requerida para la aplicación de seguros

• Habrá pólizas, habrá siniestros y habrá recibos.
• Habrá identificadores y datos diferentes para la póliza, para el siniestro y para el recibo.
• Tendremos nuestra red de oficinas y una entidad financiera como socio. Esta entidad financiera utilizará la Consulta de Póliza y Consulta de Recibo como ayuda en la toma de decisiones de cara a los créditos que conceden.

Primera aproximación para la aplicación de seguros

Como primera aproximación podría bastar con un único servicio:

• Consultar. Un único servicio que da soporte a toda la funcionalidad requerida. Permite consultar pólizas, siniestros y recibos.
  • Parámetros de entrada: Qué se desea consultar y el Identificador de lo que se desea consultar,
  • Parámetros de salida: Conjunto de datos que dependerá de lo que se ha decidido consultar.

Análisis de la primera aproximación para la aplicación de seguros

Si examinamos este servicio siguiendo los principios de identificación de servicios SOA, encontraremos lo siguiente:

• Sentido para el negocio: El servicio “consultar” es demasiado genérico, pero sí puede tener sentido para el negocio. Realmente en este caso, debería haber tres servicios:
  • Consultar Póliza.
  • Consultar Siniestro.
  • Consultar Recibo.
• No es modular. La funcionalidad de consultar una póliza puede ser semejante a consultar un recibo, pero los datos son distintos.

Por otra parte, tampoco logra un mínimo acoplamiento con sus clientes, ya que el mensaje de entrada hace referencia a una estructura común para todos los servicios. Esto añade dependencias que no son necesarias. Por ejemplo, un cambio en la consulta de póliza puede afectar a los clientes que no usan esta funcionalidad pero que usan el mismo servicio.

• No tiene el interfaz claramente definido. En el caso que se ha planteado, el parámetro de entrada es común, pero podríamos plantear otros tipos de consultas en los que como parámetro de entrada tuviéramos datos específicos dependiendo de la póliza, con lo que en ese caso, el interfaz debería ser específico.
• Seguridad. Al ser un único servicio no se puede limitar el acceso a diferentes clientes. Por ejemplo, necesitamos que nuestra red de oficinas pueda invocar las tres funcionalidades (consulta de Póliza, Siniestro, Recibo), mientras que nuestro socio (entidad financiera) no debería poder invocar a la consulta de Siniestro.

Cómo solo tenemos un servicio, no es posible lograr este nivel de autorización con los estándares de seguridad declarativa, teniendo que programar una solución ad-hoc para controlar el acceso de manera programática.

• Distribuible. Si bien el servicio “consultar” se puede implementar como un servicio web y por lo tanto es distribuible, no tiene toda la flexibilidad que nos podría aportar otro tipo de implementación. Es posible, por ejemplo, que la consulta de pólizas sea mucho mayor que la consulta de siniestros. Si en lugar de un solo servicio fuesen tres, se podría desplegar el servicio más demandado en una máquina más potente o en un mayor número de máquinas que el resto de servicios, logrando una mayor eficiencia y calidad de servicio de nuestra infraestructura.
• No es intercambiable. Al tener un solo servicio con un contrato poco definido nos impactaría mucho un posible cambio. Por ejemplo, en un hipotético caso, nuestra compañía compra un software estándar para la gestión de pólizas. Con una verdadera orientación a servicio, en el que las tres funcionalidades no estuviesen en el mismo servicio, sería sencillo cambiar el servicio de consultar póliza por este paquete comercial. Sin embargo, con esta implementación es muy difícil teniendo un impacto importante en el resto de funcionalidades que proporciona la empresa, estando expuestos a errores y pérdida de servicio. En realidad, un cambio en el servicio de consultar siniestro no tendría que afectar a la Entidad Financiera ya que no usa este servicio, pero no es así.
• No es compartible. Imaginémonos que nuestra organización llega a un acuerdo económico con otra empresa para proporcionarle pólizas. Esta nueva empresa tendrá que implementar la invocación a nuestro único servicio, teniendo que lidiar con parámetros (los de consultar siniestro y consultar recibo) que en realidad no le interesa para nada. Tal vez, en este caso, habría que decirle: tienes que mandarme 50 parámetros pero 40 tienen que venir vacios ya que no te hacen falta.

Aproximación definitiva para la aplicación de seguros

Teniendo en cuenta el análisis anterior y el sentido común, los servicios de negocio que se deberían implementar en la empresa del ejemplo, son:

• ConsultarPoliza: Un servicio que da soporte a la funcionalidad requerida para la consulta de pólizas.
• ConsultarSiniestro: Un servicio que da soporte a la funcionalidad requerida para la consulta de siniestros.
• ConsultarRecibo: Un servicio que da soporte a la funcionalidad requerida para la consulta de recibos.

Análisis de la aproximación definitiva de la aplicación de seguros

A diferencia respecto de la aproximación de un solo servicio, con el planteamiento de tres servicios:

• Sí tiene sentido para el negocio.
• Es modular, tiene cohesión (cada servicio se dedica a una cosa) y expone al consumidor únicamente la información que necesita (bajo acoplamiento).
• Cada uno de los servicios tiene el interfaz (el contrato con el cliente) claramente definido.
• Se puede securizar de manera independiente. Por seguridad declarativa se puede impedir el acceso desde la entidad financiera a la consulta de pólizas de auto.
• Es distribuible. Cada servicio se puede desplegar en una máquina diferente.
• Se puede sustituir un servicio por otra implementación sin afectar al resto.
• Lo puede invocar cualquier aplicación dentro o fuera de la organización.
• Se puede fácilmente construir (componer) un nuevo servicio más complejo a partir de los servicios anteriores.

Dificultades generales para identificar Servicios Funcionales

El camino para conseguir un buen catálogo de servicios está lleno de trampas. A continuación se describen algunos ejemplos comunes que se aplican a la identificación de servicios:

• Servicios sólo de nombre.

Los términos SOA y Servicio se utilizan con poco rigor en muchos entornos TI. Los equipos de proyecto etiquetan en ocasiones a sus aplicaciones como “orientada a servicios”, simplemente debido a la percepción errónea de que el uso de servicios Web constituye por sí solo una arquitectura SOA.

Se crean gran cantidad de servicios Web, sin tener en cuenta de la alineación con el negocio, reutilización o cualquier otra propiedad que un servicio debe tener. Esto lleva a una gran decepción cuando los beneficios esperados de SOA nunca llegan.

• Inexistencia de servicios perfectos.

En el otro lado del espectro está el peligro de tener analistas y arquitectos que modelan servicios maravillosos que simplemente no pueden ser construidos usando la tecnología actual. Esto se puede evitar a través del aseguramiento constante de que todos los esfuerzos de modelización se balancean con una dosis de realidad.

• Servicios de Babel.

Si una organización no tiene un modelo de datos canónico, los servicios son automáticamente incompatibles. El resultado es un entorno que dependerá de tecnologías de transformación y transición durante muchos años. Esto, en última instancia, inhibirá todos los aspectos de la orientación a servicios.

• Servicios Spaguetti.

Un problema que puede ocurrir cuando los servicios son definidos en múltiples niveles de granularidad es que la terminología técnica y la de negocio pueden estar tan mezcladas que los servicios pueden llegar a ser muy poco intuitivos, confusos y a veces, simplemente inutilizables.

Métodos para identificar Servicios Funcionales

En ocasiones los Analistas Funcionales tienen la necesidad de identificar los Servicios Funcionales que se necesitan para cubrir las funcionalidades descritas en los casos de uso.

A la hora de identificar servicios surgen las siguientes preguntas:

• ¿El servicio es demasiado genérico?
• ¿El servicio es demasiado específico?
• ¿El servicio tiene una granularidad demasiado grande?
• ¿El servicio tiene una granularidad demasiado pequeña?

Se mostrarán nueve métodos comunes para identificar y definir los servicios. A pesar de que estos métodos se describen por separado, en la práctica se pueden combinar.

• La descomposición de procesos de negocio.

Uno de los métodos más comunes para la identificación y la obtención de servicios, utiliza los procesos de negocio como punto de partida. El proceso de negocio se divide en sub-procesos o se descompone en actividades y tareas. Las tareas de menor nivel pueden estar formadas por pequeñas y cohesionadas “unidades lógicas de trabajo” que son soportadas por la funcionalidad que ofrecen distintos servicios.

Una gran ventaja de este enfoque es que los servicios resultantes tienen garantizado el ajuste con las necesidades funcionales de la organización. Este método es muy intuitivo, permitiendo a los equipos de proyecto usarlos para realizar pruebas de concepto y pilotos de proyectos.

Se puede dar una brecha entre procesos de negocio y aplicaciones si los servicios son sólo el modelo de negocio de acuerdo a las especificaciones de la definición del proceso y sin tomar en cuenta las consideraciones de implementación.

Además, a menos que se realice un esfuerzo de modelado en iterar a través de múltiples procesos empresariales, los servicios se pueden ajustar muy específicamente a las tareas y actividades de un proceso de negocio concreto, lo que da lugar a servicios que no se pueden reutilizar.

Incluso cuando se derivan los servicios de múltiples procesos, varias actividades pueden requerir funciones similares. Es necesario realizar una coordinación para evitar la redundancia entre los servicios definidos para los equipos de proyecto que trabajan en paralelo.

• Funciones del negocio.

Hay que tener en cuenta el contraste entre:

• La identificación de servicios basándose en un único proceso de negocio con lo que significa de estrecho vínculo entre el proceso y estos servicios.
• La idea subyacente de que los servicios deben proporcionar los medios para separar la lógica de negocio de servicios de TI.

Una posible solución a este problema es comenzar a partir de un modelo de las funciones de negocio. La identificación se abstrae de la forma en que los procesos de negocio se han implementado. Es similar al refinamiento paso a paso hacia los servicios desde el enfoque de proceso de negocio, sin embargo, en este caso la descomposición funcional de las funciones de negocio es lo que se traduce en servicios.

Conlleva los mismos riesgos que el anterior método.

• A partir del modelo de las entidades de negocio.

El propósito de la mayoría de los servicios es el procesamiento de la información de negocio. Al modelar servicios de acuerdo a los modelos de los objetos de negocio, suelen aparecer servicios del tipo CRUD. Debido a esto, se recomienda establecer modelos de datos canónicos que estandarizan el intercambio de datos entre servicios (se debe evitar que existan entidades que referencian la misma información con diferente estructura).

La dificultad principal de este método es la necesidad de modelos de datos estandarizados.

Nota: ¿Qué es un modelo de datos canónico?: Es un modelo que define la estructura de la información en una organización, siendo su objetivo no solo el limitarse a modelar los datos dentro de una sola base de datos, sino servir de referencia para todas las entidades y sus relaciones a través de todas las bases de datos de la empresa.

• Propiedad y Responsabilidad.

SOA requiere de una estructura bien definida para la toma de decisiones, dónde los roles y responsabilidades de los procesos y servicios están claramente distribuidas y asignadas. Cuando se identifican servicios, la parte que tiene la responsabilidad de poner a disposición la funcionalidad requerida determina qué servicios serán ofrecidos.

Los enfoques de diseño desempeñan un papel importante en este proceso, pero hay otras cuestiones que se deben tener en cuenta a la hora de decidirse por la opción final: Costes de desarrollo, costes de mantenimiento, gestión de ciclo de vida de las aplicaciones subyacentes, prioridades, disponibilidad de los recursos humanos, etc.

• Dirigido por objetivos de negocio (goal driven).

La mayor ventaja es que siempre está claro quién es propietario de un servicio. En otros métodos este tema puede convertirse en un punto de debate, e incluso puede derivar en consecuencias políticas. En el lado negativo, los servicios de diferentes ámbitos pueden acabar superponiéndose debido a la estructura de la propiedad requerida.

Con este enfoque, un equipo de proyecto descompone los objetivos de la empresa hasta el nivel de servicios. En este contexto, un servicio se considera como un objetivo que puede ser ejecutado a través de soporte automatizado. Por ejemplo, una meta como “aumentar la retención de clientes”, puede dar lugar a un servicio llamado “registro de clientes para el programa de fidelización”.

La ventaja es la fuerte relación establecida entre los servicios y la estrategia de la empresa. Sin embargo, surgen dos problemas: Los objetivos suelen ser subjetivos, y una buena cantidad de servicios tecnológicos no pueden ser directamente alienados con los objetivos de negocio.

La subjetividad puede provocar que dos objetivos de negocio se descompongan en dos servicios distintos, a pesar que la funcionalidad deseada es idéntica (lo que significa que hubiera sido preferible el uso de un único servicio). Además, debido a que muchas de las características TI no pueden estar directamente relacionadas con los objetivos de negocio, hay un riesgo constante de que muchos de los servicios potencialmente útiles, simplemente se pasen por alto.

• Basado en Componentes.

La esencia de la utilización de componentes TI, consiste en dividir la funcionalidad TI en unidades con máxima cohesión interna y mínimo acoplamiento externo. Los componentes son realmente unidades autónomas de funcionalidad.

Hay varios métodos para identificar componentes, pero un principio que guía estos métodos es que cada componente tiene exactamente un dueño y que las responsabilidades de cada componente tienen que ser definidas con la mayor precisión posible. Estas responsabilidades pueden ser utilizadas como punto de partida para la identificación de los servicios.

En la actualidad los proveedores de las grandes aplicaciones monolíticas (como los sistemas ERP y CRM), tienden a organizar sus aplicaciones de forma más modular y ponerlos a disposición a través de los servicios. Estos módulos se corresponden aproximadamente con los componentes.

La ventaja de basarse en los componentes es que el proceso de identificación de servicios se simplifica mucho. La mayor parte del trabajo de análisis ya se ha llevado a cabo como parte del método de desarrollo basado en componentes. Sin embargo, esto dar lugar a varios problemas: los componentes que pueden estar hechos hace tiempo, no encajen con la orientación a servicio o simplemente no respondan a la funcionalidad de negocio que se necesita.

• Partir de lo existente (Bottom-up).

Un método pragmático para una rápida definición de los servicios consiste en basarse en las necesidades inmediatas de información y funcionalidad. En este caso, el punto de partida es la funcionalidad proporcionada por las aplicaciones heredadas existentes. Se seleccionan los sistemas que proporcionan el grueso de la funcionalidad requerida por los principales procesos de negocio. Usando herramientas y asistentes, los interfaces existentes, las pantallas, transacciones, consultas y tablas son accesibles a través de los servicios.

La principal ventaja de este método es que requiere poco tiempo para llegar a una primera definición de los servicios. Se trata de un enfoque apropiado si se requiere con urgencia la funcionalidad de las aplicaciones existentes.

Se reaprovecha el software actualmente existente en la empresa aunque se hace problemático el orientar los servicios resultantes a una verdadera orientación a servicios de negocio ya que el resultado normalmente da lugar a servicios muy específicos y poco reusables.

• Análisis de las necesidades de la aplicación de frontal (frontend).

Analizando la aplicación web o de escritorio que sirve de interfaz con el usuario se puede ver rápidamente los servicios que necesita. Por ejemplo, si en una pantalla se muestran las pólizas que tiene un determinado cliente, obviamente se necesitará un servicio al que se le pasa el identificador del cliente y que devolverá un listado con la consulta que se necesita para presentar los datos al usuario.

Sin embargo, este enfoque tiene un problema importante, se están acoplando los servicios a una aplicación de frontal cuando los servicios deben desconocer quién los convoca. Además casi con total seguridad, los servicios resultantes serán muy específicos para ese caso concreto de frontal.

• Requisitos No Funcionales.

Este método utiliza los requisitos no funcionales como la entrada principal para identificar servicios. No es un método como tal, sino más bien un conjunto de técnicas que se pueden utilizar sobre los otros métodos.

Después de la identificación preliminar de un conjunto de servicios a través de las otras aproximaciones de identificación, el futuro proveedor de servicios verifica la viabilidad de los requisitos no funcionales de un futuro consumidor de servicios. Si los requisitos no funcionales son inviables, es más importante que los servicios puedan ser rediseñados que los principios de diseño que se han seguido en los métodos de identificación.

En la fase de Diseño Técnico, dos requisitos no funcionales que normalmente se tienen que tener en cuenta son seguridad y rendimiento. Por ejemplo: Se descubre que la funcionalidad que aporta el servicio X es necesaria para las aplicaciones A y B. Si la aplicación A se ajusta a los requisitos de seguridad impuestos en el servicio X y la aplicación B no puede, quizás tenga sentido dividir el servicio X en dos servicios separados, servicio securizado y servicio no securizado.

Por otra parte, si una organización decide implementar SOA a través de servicios Web, algunos servicios pueden no ser capaces de ofrecer el rendimiento necesario. Las opciones que se pueden realizar son la fusión de múltiples servicios (reduciendo la cantidad de necesidades de comunicación entre los servicios).   

Patrones Funcionales

Hasta ahora cuando hemos oído hablar de Patrones en Ingenieria del Software ha sido sobre Patrones de Diseño, pero hay más patrones...

La definición de Patrón según la Academia de la Lengua Española es "Modelo que sirve de muestra para sacar otra cosa igual", y eso es lo que haremos con las funcionalidades de las aplicaciones. Sacaremos modelos comunes en las funcionalidades de las aplicaciones que nos sirvan para no tener que pensar ni en cómo resolver ni en cuánto nos cuesta algo que ya hemos realizado antes.

Esto seán los Patrones Funcionales, cada Patrón describirá una serie de tipos de funcionalidades comunes que se encuentran en la mayoría de proyectos de desarrollo de aplicaciones software. Y gracias a ellos podremos reutilizar funcionalidades ya descritas de modo general, a las que tendremos que añadir las particularidades de las aplicaciones.

El contrato para cada Patrón Funcional, tendrá los siguientes apartados:

• Objetivo. ¿Qué resuelve el patrón?
• Estructura. ¿Qué casos de uso componen el patrón? y ¿qué hace cada caso de uso? ¿El patrón necesita datos de entrada? ¿El patrón devuelve datos de salida?
• Diagrama. ¿Cómo se relacionan los casos de uso del patrón?
• Estimación. ¿Cuánto cuesta en términos de UCP, cada caso de uso? ¿Qué catalogación de complejidad tiene cada caso de uso?

El modo de presentación de los Patrones Funcionales será el siguiente:

• Un Catálogo de Patrones dónde indicaremos el nombre del patrón, una descripción breve y el enlace a la documentación del patrón.
• Un documento para cada Patrón Funcional, que incluirá todos los apartados definidos.

Inicialmente comenzaremos abordando una serie de patrones básicos:

• Patrón Carga masiva de ficheros.
• Patrón CRUD Simple
• Patrón CRUD Medio
• Patrón CRUD Complejo
• Patrón Histórico

,para ir aumentando periódicamente la lista de patrones.

El perfil de un Analista Funcional

Me estoy encontrando numerosas ofertas de trabajo para Analista Funcional. Entre ellas, alguna como esta: Analista Funcional Senior con dos años de experiencia, estudios requeridos Formación Profesional y 30.000 euros de salario.

Hay un vacio importante en este área. La mayoría de las veces, los analistas son programadores que para subir de sueldo y de categoría comienzan a realizar las tareas de análisis, pero no tienen las habilidades necesarias para realizar buenos trabajos. Así ocurre luego, que una mala o insuficiente especificación tiene una repercusiones negativas en la realización del proyecto.

También a veces las propias consultoras suben a sus programadores, aún sabiendo su no preparación, a analistas, con el objetivo de facturar más por ellos a sus clientes.

Ante la pregunta que nos podemos hacer respecto de qué tiene que saber un Analista Funcional, hay organismos internacionales que aportan certificaciones sobre este área. Hablo del International Institute of Business Analysis que aporta el Business Analysis Body of Knowledge (BABOK). 
Esta guía identifica las áreas de conocimiento del Análisis de Negocio que están normalmente reconocidas y aceptadas como buenas prácticas.

Las Áreas de Conocimiento no definen una metodología de Análisis de Negocios. Definen lo que un Analista de Negocio (BA) necesita conocer para trabajar dentro de un proceso de Análisis o sobre una Metodología de Desarrollo de Soluciones.

En la guía se encuentran definidas las áreas de:

• Análisis Empresarial, 
• Planeamiento, 
• Gestión de Requerimientos (incluye el control de cambios), 
• Obtención de Requerimientos (con sus diversas técnicas), 
• Análisis y Documentación de los Requerimientos, 
• Evaluación y Validación de la Solución y,
• Comunicación de los Requerimientos (Plan de comunicación, conflictos, formatos, aceptación).

En este enlace se puede ver la versión 2.0 del BABOK 

Las certificaciones que el IIBA propone son las siguientes:

• CCBA, Certification of Competency in Business Analysis
• CBAP, Certified Business Analysis Professional (para analistas senior)

Creo que cualquier Analista debería si no tener estas certificaciones, si al menos conocer las áreas de conocimiento que proponen. Curiosamente, en España no hay representación del IIBA...

Arquitectura Funcional

Suelo echar de menos en la mayoría de las organizaciones, un área de Arquitectura Funcional. El nombre plantea confusión, para mí la Arquitectura Funcional debe plantear soluciones funcionales a problemas como:

• Aplicaciones orientadas a obtener un Producto con "n" clientes.
• Aplicaciones Multicanal.
• Aplicaciones BPM.
• Aplicaciones de Portal.
• Aplicaciones ERP-CRM.
• Definición de Agrupaciones o paquetes funcionales.
• Definición de Fases.

Lo que deben describir entre varios aspectos, son los posibles patrones de análisis a utilizar, ¿cómo enfocar funcionalmente cada tipo de aplicación?, desde la toma de requisitos hasta el diseño funcional.

Esta materia definirá estrategías comunes ante los mismos problemas. No es metodología, ya que no dice por ejemplo cómo hacer un modelo de casos de uso; lo que si hará será aconsejar en el cómo plantear un modelo de casos de uso ante una tipología de aplicaciones.

A partir de una estrategía funcional clara, podremos elegir el mejor ciclo de vida posible para orquestar el proceso de desarrollo.

Consideraremos cada uno de los tipos de aplicaciones planteadas, como una Arquitectura Funcional de Referencia. Por ejemplo, cuando nos venga un proyecto que tiene que desarrollar una aplicación SAP, utilizaremos la arquitectura de referencia ERP-CRM para obtener un Diseño Funcional que cubra las necesidades de este tipo de aplicaciones. Y eso sí, para el siguiente no tendremos que inventar nada.

Dos maneras de enfocar un nuevo Proyecto Software

A la hora de comenzar un proyecto debemos analizar a nuestros participantes, esto nos tiene que permitir enfocar el modo de relación en el proyecto, el cuál es fundamental para conseguir los objetivos que pretendemos.

Tendremos:

• Proyecto con participantes que van a trabajar en plan "Buen Rollo". Esto no deja de ser síntoma que algo tienen que esconder, pero aunque esto sea así, el clima que se forma excusa los fallos y apoya continuamente. Si no se controla se convierte en un cachondeo ya que los que fallan se piensan que todo el monte es orégano.
• Proyecto con participantes que van a trabajar en plan Borde. Todos muy profesionales y a la mínima que se falla en algo, hachazo. Muy efectivo de inicio pero poco solidario y a veces finalmente no muy productivo, ya que los que fallan se alían y hacen la vida imposible al resto.

Yo prefiero trabajar con los del Buen Rollo, aunque cuando me ha tocado ser él que dirige, a veces es un poco estresante. Si hay algún miembro caradura se puede fracasar y tener que ir al plan Borde.

Es importante que ya de inicio en la reunión de lanzamiento, te posiciones. A mí me ocurrió hace poco que en una reunión en la que vas de "buen rollo", una superlista empezó a atacar, pues nada se quita uno el traje de buenrollista y saca la coraza y la espada, y a atacar también. Finalmente, llegamos al "buen rollo", ya que la mayoría de las veces, los que van en plan "borde", no deja de ser también porque tienen algo que esconder y piensan que ponerse a la defensiva les evita que les saquen los colores.

Saludos y mi mejor "buen rollo"...

Tres formas diferentes de ver el producto Análisis Funcional

En las decisiones que tenemos que tomar respecto de nuestros proyectos deberíamos plantearnos lo siguiente:

TRES VARIANTES A LA HORA DE VER Y EMPLEAR EL ANÁLISIS

• El proyecto utiliza el modelo de análisis para describir los resultados del análisis, y mantiene la consistencia del modelo a lo largo de todo el ciclo de vida del software.

• El proyecto utiliza el modelo de análisis para describir los resultados del análisis pero considera a este modelo como una herramienta transitoria e intermedia. Más adelante, cuando el diseño y la implementación están en marcha, se deja de actualizar el análisis. Cualquier “tema de análisis” que aún quede se resuelve como parte integrada dentro del trabajo de diseño.

• El proyecto no utiliza en absoluto el modelo de análisis para describir los resultados del análisis. En cambio, el proyecto analiza los requisitos como parte integrada en la captura de requisitos o en el diseño. Puede ser justificable si, por ejemplo, los requisitos son muy simples y/o son bien conocidos, si es fácil identificar la forma del sistema, o si los desarrolladores cuentan con una cierta comprensión, intuitiva pero correcta, de los requisitos, y son capaces de construir el sistema de manera correcta.

Para las dos primeras se debe sopesar las ventajas de mantener el modelo de análisis con el coste de mantenerlo durante varias iteraciones y generaciones. Se debe hacer un análisis coste/beneficio.

La tercera variante se debería solo emplear para sistemas extraordinariamente simples.

La decisión de una u otra variante debe ir en función de aspectos como Grado de confianza con el cliente, Madurez de nuestros equipos, Conocimiento del negocio, etc…, pero cualquiera que sea nuestra elección, deberíamos respetarla a lo largo del ciclo de vida del proyecto.

Requisitos Funcionales vs Casos de Uso

En la mayoría de las organizaciones en las que he trabajado, se realiza una Toma de Requisitos bastante detallada y posteriormente un Análisis Funcional basado en los requisitos recogidos.

¿Qué es lo que se hace?, se capturan y describen los requisitos y después se traslada a un modelo de casos de uso, dónde se vuelve a describir la funcionalidad deseada; posiblemente si se hace bien, con un enfoque más orientado al usuario y con una estructura más clara.

Ahora bien, ¿qué conseguimos con esto?, más horas de análisis, más horas de validaciones, tener repetido lo que tiene que hacer el sistema en dos artefactos diferentes, inconsistencias, etc...

La captura de los requisitos se debe realizar a través de los casos de uso. Si se decide no utilizar casos de uso, se puede realizar a través de un documento de análisis que contenga las funcionalidades y su estructuración.

Si para realizar el análisis de una aplicación, primero se capturan las necesidades, luego se hace un documento de toma de requisitos que además se tiene que validar y finalmente se hace un modelo de casos de uso (con su validación correspondiente), daremos la razón a todos aquellos que piensan que el proceso de Análisis es demasiado pesado.

CONCLUSIÓN FINAL: Los requisitos funcionales se deben capturar a través de los casos de uso. No se debe perder el tiempo en hacer un documento de requisitos funcionales.

Más adelante hablaremos sobre las Historias de Usuario, aunque para ello tendremos que poner el contexto del tipo de proyecto que manejamos.

Aclaración de términos para Análisis

Hola, vamos a aclarar algunos términos que normalmente mezclamos equivocádamente. 

• Necesidad: Lo que pretende el cliente o desea que se le proporcione para su aplicación.
• Lo que se está pidiendo que el sistema haga.
• Se consideran equivalentes los siguientes términos:
• NECESIDAD = ISSUE = CARACTERÍSTICA = REQUERIMIENTO = REQUISITO CANDIDATO = Requisitos de Usuario. 

• Requisito: También denominado Requisito del Sistema. Capacidad que debe tener el sistema para satisfacer las necesidades de los usuarios del sistema. Incluye Requisitos Funcionales y Requisitos No Funcionales.
• Lo que se necesita para cumplir con lo que se está pidiendo que el sistema haga.

• Caso de Uso: Secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia.
  • Estructuración de la funcionalidad requerida en el sistema, a través de secuencia de pasos e interacciones con sistemas externos (usuario).

Ejemplo:

Necesidad: Contestar un mensaje de correo.

Requisito: Tener un ordenador conectado a Internet; tener un software de correo electrónico; Poder seleccionar destinatarios; Poder modificar el mensaje; y más requisitos...

Casos de Uso: Seleccionar Destinatarios; Editar Mensaje; Insertar Firma; etc...

Un saludo,