Casos de Abuso, Parte 6: Un escenario y un caso de uso es lo mismo

Simplemente no. Muchas veces los términos se usan indistintamente, yo mismo me he visto diciendo “caso de uso” cuando realmente quiero decir “escenario”. Pero ese es otro problema.

 Figura 1: Representación Visual de un escenario de un caso de uso

Un escenario es el flujo que sigue un caso de uso durante su ejecución de acuerdo a un estímulo recibido desde el exterior, vía el Actor del caso de uso, es decir, el usuario. Las cosas así, un caso de uso puede derivar en muchos escenarios, docenas, cientos o miles, dependiendo de la complejidad y el tamaño del caso de uso. Esta es la razón principal por la cual no existe el concepto de Pruebas Exhaustivas, porque es inviable probar con anticipación todos y cada uno de los escenarios de un caso de uso. Un escenario es una instancia de un caso de uso, casi de la misma forma como un objeto es una instancia de una clase. Me refiero a que una instancia de un caso de uso es un camino concreto a través del cual la pareja actor-caso de uso es reemplazada por una persona específica (una instancia de un actor), donde valores y respuestas específicos son dados, y solamente un camino simple es tomado a través de uno o más posibles flujos del caso de uso. Los escenarios están descritos de una manera narrativa, incorporan características concretas de los usuarios y de la materia prima que estos entregan al sistema.

Un caso de uso, por su parte, está constituido por secuencias paso a paso de acciones que conforman el comportamiento de un sistema, asociados a un actor específico. Un caso de uso es muy detallado y típicamente incluye actores, una breve descripción, precondiciones, la secuencia principal y las alternativas, y hasta flujos de excepción; también describe el estado del sistema una vez que ha terminado cada secuencia, es decir, las poscondiciones.

A propósito de este mal uso, otra situación que nos está pasando es que nuestros diseños de software carecen de los escenarios de usuario como entrada principal, lo que constituye una falta importante puesto que los escenarios incluyen todos los detalles que los diseñadores requieren entender sobre lo que los usuarios están tratando de hacer y lo que ellos necesitan. Muchos desarrolladores que nunca ha escuchado acerca de un escenario de uso son capaces de adaptar los casos de uso para incluir esta información de usuario, rica y contextual.

Impacto en la calidad: Alto.

Figura 2: Representación Visual de otro escenario de un caso de uso

Obsérvese de las dos figuras que las posibilidades son virtualmente infinitas.

Casos de Abuso, Parte 5: El caso de uso contiene detalles de formularios (pantallas) y otros aspectos técnicos (bases de datos, componentes, etc.)

Este error es reiterativo y cuando digo eso me refiero a que siempre hago énfasis en que no es así, pero algunos analistas funcionales insisten en hacer exactamente lo contrario.

Un caso de uso especifica lo que debe hacer un sistema de software. No es correcto incluir detalles de la interfaz gráfica resultante, como botones, cuadros de texto, listas de opciones, entre otros, lo mismo que otros mecanismos relativos a los elementos de software con los que se implementará el caso de uso, como referencias a componentes de software, a librerías de acceso a datos, o a tablas u otros objetos de bases de datos. Todo esto hace parte del “como” se implantará el caso de uso en el sistema una vez que esté terminado, son detalles poco entendibles para el usuario final, interesado principal en la especificación del caso de uso y de los requisitos en general.

Recordemos además que un caso de uso detalla la interacción entre el actor y el software, desde el punto de vista del usuario; es decir, al usuario solo le interesa conocer sobre los insumos que tiene que proporcionarle al sistema a través de ese caso de uso y también de los resultados que el sistema le sirve de vuelta, no cómo ese resultado es calculado, encontrado, o procesado al interior del sistema.

Ahora bien, suele ocurrir que algunos usuarios, a fuerza de lidiar durante tantos años con los sistemas, conocen de nombres de tablas y hasta de procedimientos almacenados y son capaces de establecer explícitamente de qué tabla quieren que se tome un dato o cual procedimiento requieren ejecutar en cierto momento. Estos detalles se documentan, pero se formalizan durante la etapa de Análisis y Diseño del caso de uso, cuando este se suplementa.

Los requisitos del software, y con ellos los casos de uso cuando se utilicen como mecanismo de especificación, son independientes de diseño y de implementación.

Impacto en la calidad: Medio.

Casos de Abuso, Parte 4: Resumen ejecutivo

Recapitulemos. Tenemos una lista corta de escenarios en donde estamos usando mal los casos de uso como instrumentos para identificar, organizar, documentar y administrar requisitos de software, tanto funcionales como no funcionales.

Estos son los casos enumerados hasta el momento:

1.    El caso de uso es la única documentación necesaria para construir el software.

Impacto en la calidad: Alto.

2.    El caso de uso se usa en todos los casos.

Impacto en la calidad: Bajo.

3.    Lo que no está documentado en los casos de uso no hace parte del sistema.

Impacto en la calidad: Medio.

4.    El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.

Impacto en la calidad: Medio.

Entonces, ya sabemos que la especificación de requisitos de software (ERS) viene, o puede aparecer, en recipientes de distintos tamaños y diferentes formas y colores: algunos son cacharros escuetos pero con significado y suficiencia para quien los elabora y para los interesados en los mismos, otros son cristalerías sofisticadas que se aproximan a lo mundano, en el sentido de cosmopolita. Pero contienen requisitos de software, al fin y al cabo.

En términos de artefactos de especificación y modelado de sistemas de información, estoy hablando de folios de especificación funcional, con sus requisitos en prosa y todo el detalle aledaño que siempre los acompaña; pero también me refiero a la descripción de procesos del negocio, desde macro-procesos, hasta tareas simples y atómicas, pasando por procesos y subprocesos; representaciones de herramientas visuales como prototipos estáticos y simuladores.

También hago alusión a diagramas de UML, como  diagramas de actividad y de estado, diagramas de procesos, diagramas de contexto y mapas mentales, entre algunos otros; descripción de reglas y políticas del negocio; acuerdos de entendimiento entre los usuarios y el área de tecnología; listas de deseos escritas a mano; y, las más usadas, historias de usuario y casos de uso. Incluso, con las nuevas tecnologías, los requisitos de software bien pueden aparecerse en formato de videos o audios digitales, fotografías de alta definición capturadas por teléfonos inteligentes, mensajes electrónicos y trinos de 140 caracteres o menos.

Usualmente, la ERS se exhibe en una combinación de dos o más de estos instrumentos y lo único que importa es que provenga de las personas apropiadas e interesadas en el producto de software y que cada requisito cumpla o pueda cumplir con algunos atributos o rasgos de calidad:

·         Claridad

·         Atómicidad

·         Precisión

·         Verificabilidad

·         Necesidad u oportunidad

·         Priorización

La ERS, por su parte, debe ser:

·         Independiente de diseño

·         Completa

·         Consistente

·         Rastreable

·         Modificable / Extensible

Ahora ya sabemos cómo corregir algunos de esos defectos. ¿Ustedes qué creen?

Salud@s.

Casos de Abuso, Parte 3: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración

El modelo iterativo de desarrollo de software dicta que podemos construir el sistema mediante incrementos en períodos de tiempo relativamente cortos y con un objetivo fijo. A estas fases de tiempo se les conoce como Iteraciones y al producto (resultado) de la fase se le conoce como Incremento.

En otras palabras, una iteración es un mini-proyecto con una salida bien definida: una versión incrementada, estable, probada e integrada del producto de software, con su documentación asociada. Pues bien, una de las faltas típicas que cometemos durante el ciclo de vida del software tiene que ver con esto.

Veamos de qué se trata:

Caso de Abuso 4: El caso de uso se identifica, elabora, diseña, implementa y prueba en la misma iteración.

Este es un error muy común al iniciarse en un proceso iterativo. Un caso de uso pasa por varias etapas o períodos durante su ciclo de vida: desde la identificación o descubrimiento del caso de uso, hasta la puesta en ejecución del mismo, pasando por la Ingeniería del Caso de Uso (conocida entre nosotros como la Ingeniería de Requisitos), el Análisis y Diseño, la Implementación, las Pruebas y el Despliegue final.

Y cada una de estas etapas ocurre a través distintas fases del proyecto y de diferentes iteraciones. Durante la fase de inicio o visionamiento del proyecto, descubrimos un número significativo de casos de uso y algunos de ellos pasan a la etapa de Ingeniería de Requisitos; muy pocos de estos casos de uso llegan a la etapa de Análisis y Diseño y ninguno llega a la Implementación.

Más adelante, durante la fase de Planeación o Elaboración del proyecto, los llamados casos de uso arquitectónicos, de los identificados en la fase previa, llegan a las etapas de implementación y pruebas, mientras que otros casos de uso son descubiertos y otros llegan al período de Ingeniería de requisitos.

Durante las siguientes fases del proyecto, algunos pocos casos de uso son identificados, los últimos, y los demás pasan, iteración tras iteración, por las etapas expuestas; pero nunca, un caso de uso se identifica y llega a implementarse en la misma iteración, por muy simple que sea. Eso sería apenas una simple coincidencia y, casi siempre, un error.

Muy relacionado con este abuso está el abuso No. 12, aunque hay diferencias fundamentales entre aquel y este. (Lo veremos en su momento)

Impacto en la calidad: Medio.

PD. Sobre iteraciones, los invito a leer mi artículo Gerencia de Proyectos Iterativos en la Revista Project Management Iberoamericano de la Asociación Española de Profesionales en Dirección de Proyectos.

Casos de Abuso, Parte 2: El caso de uso es la única documentación necesaria para construir el software

Abusar.

(De abuso).

1. intr. Usar mal, excesiva, injusta, impropia o indebidamente de algo o de alguien. Abusaba DE su autoridad.

Real Academia Española © Todos los derechos reservados

Caso de Abuso 3: El caso de uso es la única documentación necesaria para construir el software.

Quizás esta idea surge de la premisa de que el proceso de desarrollo de software es dirigido por casos de uso [1], que es algo mucho más amplio y totalmente distinto. Además, está el factor tiempo que siempre hace falta en los proyectos de desarrollo de software.

Un caso de uso es el primer repositorio de documentación en un proyecto, puesto que es el artefacto que legitima los requisitos funcionales del software. Sin embargo, después del caso de uso y antes del código fuente hay un abismo sobre el que debemos construir un puente para ir desde la solicitud del usuario, su problema y sus necesidades, hasta un sistema de software que soporte su proceso, que resuelva su problema y cubra sus necesidades.

Ahora bien, hay casos de casos: están los llamados casos de uso arquitectónicos o más complejos, que bien podrían representar alrededor del 20% del total de casos de uso de un proyecto. A estos casos de uso debemos aplicarles rigurosamente el proceso: Análisis, Diseño, Implementación, Pruebas, Despliegue y vuelta a empezar. Y durante el Análisis y el Diseño se construyen una serie de artefactos que van desde documentos anexos hasta diagramas (de UML) de casos de uso, de secuencia, de comunicación, de clases, de estados, de actividad y de entidad-relación, entre otros. También están los requisitos no funcionales o especiales que aplican a cada uno de esos casos de uso, el pseudocódigo y los prototipos; asimismo, están los casos y procedimientos de prueba.

Es principalmente durante el período de Análisis y Diseño del caso de uso cuando ocurre la suplementación del mismo, es decir, la adición de detalles técnicos y no funcionales al caso de uso. Y en todas estas actividades intervienen todos los miembros del equipo del proyecto: unos elaboran y presentan, otros retroalimentan, complementan, realizan el siguiente paso y también lo presentan, y así, en una espiral en la que el producto se va gestando hasta quedar terminado.

Luego están los demás casos de uso del proyecto, el otro 80%. Unos son más complejos que otros desde el punto de vista de diseño, mientras que algunos son más críticos que otros desde la perspectiva del usuario. Muchos de estos casos de uso, sino todos, también deben someterse al mismo proceso que los anteriores. Lo que varía es la severidad o formalidad con que se elaboren todos esos artefactos.

Dependiendo del tipo de proyecto, de los aspectos legales del mismo y de otras variables del entorno, será necesario realizar cada documento siguiendo plantillas formales del proceso de desarrollo, casi con rigurosidad científica: diagramas de UML bien construidos y detallados, tantos como sean necesarios para entender el producto, documentos sujetos al escrutinio de revisiones técnicas y de estilo, con listas de chequeo formales y con todas las excepciones consideradas. Algunos casos de uso requerirán de tres, cinco o más diagramas de interacción, por ejemplo; otros necesitarán sólo uno de estos diagramas.

En otros proyectos, menos formales desde el punto de vista legal (aunque es difícil imaginar tal cosa), será suficiente con que estos artefactos se elaboren en reuniones de análisis y diseño en un tablero donde todo el equipo de desarrollo pueda verlos, opinar, tomar nota y entenderlos, que es el objetivo último del modelado.

La categoría de las herramientas a usar también depende de la complejidad técnica y de la formalidad legal: para unos proyectos basta lápiz y papel, o tiza y tablero, mientras que para otros serán necesarias herramientas sofisticadas de Ingeniería de Software.

En cualquier caso, nunca hay que perder de vista que el software, por naturaleza, es complejo; y que construir software, por naturaleza, es una actividad compleja. También, que las herramientas con las que se construye software (que casualmente están hechas de software) también son complejas. Y con este nivel de complejidad, no es posible que algo simple, como el caso de uso, sea capaz de resolver nuestro problema sin más colaboración.

Impacto en la calidad: Alto.

Referencias

[1]   Luis Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html, 08 mar. 2007.

La Parte 1 de este análisis lo encuentras en: http://gazafatonarioit.blogspot.com/2012/09/casos-de-abuso-parte-1.html

Sobre abecés, anatomía y prácticas de casos de uso y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en este mismo Gazafatonario IT.

http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html

¿Es maduro tu proceso de Ingeniería de Requisitos?

Hace algún tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí que la cultura orgánica tiene su propio proceso natural de supervivencia y éxito y que siempre debía medir cuidadosamente lo que es adicionado y es removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser “interno” o “externo” al proceso.

Fue una época en que puse en práctica algunos de los principios memorables de Deming en Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar prácticas probadas en la industria, no solo la última moda, lo que escuchamos en la conferencia del día anterior o lo que leímos en el último artículo de la IEEE.

Y lo más importante, difundía a mil voces que debemos ser prácticos, que debemos entregar la información que se necesita, cuando se requiere y en un formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos que optimizamos fue este de la Ingeniería de Requisitos.

Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la práctica qué significa identificar, documentar y administrar requisitos de software de una manera formal y razonable? Según el SEI (siglas en inglés del Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos son manejados y las inconsistencias con los planes de proyecto y los productos de trabajo son identificadas”.

Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de Administración de Requisitos), es que esas inconsistencias deben detectarse a tiempo porque cualquier cambio que involucre requisitos es altamente costoso para el proyecto y para los participantes en el mismo.

Para manejar los requisitos, el SEI recomienda:

·         Entender los requisitos

·         Acordar los requisitos con todos los involucrados

·         Administrar los cambios a los requisitos

·         Mantener una rastreabilidad bidireccional de los requisitos

·         Identificar las inconsistencias entre el trabajo del proyecto y los requisitos

Parece sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y, sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y acordar requisitos entre las personas que están más involucradas en el proyecto, como los Analistas y los usuarios que quienes empiezan a llegar a medida que avanza el ciclo de vida, como los programadores o los certificadores.

Manejar los cambios, naturales por demás en un proyecto típico de software, es muchas veces otro dolor de cabeza para los participantes. Hay quienes creen que una solicitud de cambio es algo de menor valía, cuando la experiencia nos ha enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay un impacto significativo y hay costos ocultos que solo los experimentados son capaces de descubrir a tiempo.

Por su parte, mantener una trazabilidad adecuada de los requisitos en ambas direcciones, lo que significa tener un mapa desde las necesidades del usuario y características del software, hasta el código ejecutable, pasando por los casos de prueba y otros artefactos importantes, es algo que solo se puede lograr adecuadamente con el uso de herramientas especializadas. En proyectos pequeños es posible que un Excel sirva, pero en algo más elaborado necesitamos de los instrumentos apropiados.

En cualquier caso, estas prácticas recomendadas (y esta es la palabra clave: “recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello más adelante.

Ventajas y Desventajas del Uso de Prototipos

Algunas Ventajas del uso de prototipos

1.       Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.

2.       Como información complementaria a los requisitos constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.

3.       Son más fáciles de abordar con los usuarios finales.

4.       El usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.

5.       Se reduce el riesgo o la incertidumbre sobre la implementación del software.

6.       Su uso redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.

7.       Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.

8.       Permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.       El usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.

2.       Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.

3.       Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.

4.       Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta suplementaria a la especificación de requisitos (funcionales). Con esto en mente, es posible que los usuarios revisen y aprueben estos prototipos durante la fase inicial del proyecto. Más adelante, el usuario puede confirmar su grado de satisfacción por los prototipos, más cercanos al producto final.

La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.

El uso de prototipos en el ciclo de vida de construcción del software

 Los prototipos son una técnica ampliamente usada para descubrir y documentar requisitos y casos de uso. En este caso hablamos de los prototipos de la interfaz de usuario, es decir, de todo lo que tiene que ver con la interacción usuario-máquina.

Los prototipos son muy útiles para refinar la especificación de requisitos funcionales del software, específicamente en todo lo que tiene que ver con la descripción de pantallas o formularios de entrada de datos, formulario de salida de datos (consultas), reportes, las opciones de navegación y, en general, toda la carta de navegación del usuario a través del software.

Existen prototipos rápidos y prototipos evolutivos. Los primeros son aquellos que se realizan en las primeras etapas del ciclo de vida y son usados para solucionar inquietudes iniciales relacionadas con la interfaz de usuario que no están claras o precisas en la documentación textual de los requisitos. Estos prototipos pueden ser elaborados en papel o en herramientas básicas como MS-Office (Word, Power Point, Excel, Visio).

Los prototipos evolutivos son artefactos más elaborados que se construyen durante la fase de diseño del software como complemento a la especificación de requisitos (y casos de uso) y que están muy cercanos al diseño final de la solución. Normalmente son hechos con las mismas herramientas con las que será construido el software o con alguna herramienta de automatización que permita generación de código fuente o algo parecido.

Hay distintos aspectos a tener en cuenta durante el uso de prototipos:

•  Tipo de problema a resolver: si el problema es no-estructurado, novedoso, complejo o de manejo de información con un alto grado de personalización para un usuario o un grupo de usuario, entonces la técnica es muy útil.
•  Conocimiento de los requisitos: si se desconocen los detalles de los requisitos del software, si existe poca información al respecto, los prototipos son útiles.
•  Necesidad de revisar, evaluar y aprobar los requisitos: si los procedimientos o controles exigen que los requisitos del software sean revisados, evaluados y aprobados por usuarios y otro tipo de personas, los prototipos serán de gran ayuda a la hora de tomar decisiones.
•  Este aspecto es crucial en muchas compañías ya que el alto grado de formalidad que exigimos para la especificación de requisitos, que tiene carácter contractual, exige que no solo los usuarios revisen y aprueben los requisitos y casos de uso, sino que estos deben ser revisados y valorados en distinto grado por personas de distintas áreas.

En estos casos es cuando los prototipos juegan un papel muy importante ya que aclaran situaciones que no están precisas en los documentos de texto. Sobre todo, con el bajo grado de madurez que tienen los documentos de requisitos y de casos de uso en el medio.

Otros aspectos a tener en cuenta en el uso de prototipos son: la cantidad y calidad de los riesgos del proyecto/requerimiento, no disponibilidad de los usuarios para revisiones y aprobaciones, uso de nuevas tecnologías o la falta de experiencia en el uso de esas tecnologías, entre otros.

Algunas Ventajas del uso de prototipos

1.  Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2.  Como información complementaria a los requisitos (y casos de uso) constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3.  Son más fáciles de abordar con los usuarios finales.
4.  Precisamente, el usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
5. Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6. En general, el uso de prototipos redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
7. Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
8. Permite a todos los involucrados (usuarios y equipo de trabajo, incluyendo proveedores) entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.  En general, encontramos que el usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
2.  Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
3.  Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
4. Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta complementaria, una técnica más, para la especificación de requisitos (funcionales), incluyendo casos de uso. Con esto en mente, es posible que los usuarios revisen (previa presentación “en vivo”) y aprueben estos prototipos durante la fase de Visión del proyecto/requerimiento. Más adelante, al final de la fase de Diseño (Planeación), el usuario puede confirmar su grado de satisfacción por los prototipos, estos ya más cercanos al producto final.

Tanto los primeros como estos últimos prototipos deben incluir el diseño de formularios de captura o ingreso de datos, formularios de consulta, reportes, opciones de navegación (menú), mensajes de usuario, ayudas en línea, entre otros aspectos. La única diferencia entre unos y otros prototipos debería ser la herramienta usada en la construcción de los prototipos y la precisión (menor en Visión, mayor en Planeación) de tales prototipos.

La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.

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.

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