TestingBaires

Este debate pueden seguirlo uniéndose al grupo de discusión ‘Análisis Funcional‘ dentro de la red LinkedIn, administrado por Daniel Mónaco.

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.

Autor: Luis Antonio Salazar Caraballo
Consultor Senior en Metodologías y Arquitectura de Software

Les recomiendo acceder al siguiente 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

.

A continuación, les dejo algunos de los comentarios publicados por los miembros de este grupo y respuestas del autor

Comentario 1
Uno de los temas más importantes, es que debe contemplar la posibilidad de expandir el negocio y/o nuevos nichos, ya que muchas empresas hoy por hoy tratar de llegar aguas arriba y aguas abajo con respecto a sus productos producidos, es decir toda la cadena de valor de un proceso productivo. Todo esto debe ser medible con indicadores de gestión y todo esto debe contemplarlo un buen análisis funcional, porque lo más importante es que estos indicadores contemplen la información más relevante para tomar excelentes decisiones que repercuten en el negocio a corto, mediano y largo plazo. Saludos para todos!!!

Comentario 2
Agrego un detalle importante, en los análisis funcionales, no solo se debe relevar y analizar lo que se ve en la empresa, también a donde quiere llegar la empresa y como va a gestionarlo, es decir debe contemplar los indicadores de gestión.

Comentario 3
Sin duda alguna. No 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.

Comentario 4
Sumo un granito de arena más al tema. Es muy importante la reunión de presentación del caso de uso, la que yo llamo “reunión de análisis”. Principalmente, como dice Luis la idea es que todos salgan con el mismo mapa mental del tema y se eliminen las ambiguedades, pero también sirve para ajustar temas entre lo funcional y lo técnico, dándole una mirada técnica a la definición del analista. Ejemplos de esto pueden ser definiciones que de una u otra forma afectan a la performance en diferente manera, o definiciones que dada la tecnología a utilizar no se pueden respetar al 100%, etc.
Y, aunque parezca una recomendación obvia, siempre hay que insistir en que los participantes de la reunión lleguen a la misma habiendo leído y analizado el caso de uso, para que esta reunión sea lo mas efectiva posible.

Comentario 5
De hecho, 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.