Casos de Uso, Motivación
Les dejo aquí parte del debate que se ha generado desde el grupo de discusión en LinkedIn: Análisis Funcional, administrado por Daniel Mónaco
Enunciado de la discusión principal:
Si los usuarios no leen los casos de
uso, no importa qué tan buenos sean, qué tan bien escritos estén, estos
no servirán de nada.
¿Pero basta con que los casos de uso estén bien escritos o estructurados para motivar a nuestros usuarios a leerlos?
¿Basta con que sean fáciles de entender?
¿Influye el nivel de detalle con que estén escritos los casos de uso
para que sean recibidos y leídos con prontitud por los usuarios?
De hecho, ocurre mucho que un caso de
uso bien está bien detallado es porque contiene aspectos que no son
“aptos” para usuarios u otros interesados y en cambio son apropiados
para otros miembros del equipo del proyecto.
Así que, ¿cuáles son esos estímulos que
le podemos dar a un usuario para que tome tiempo de calidad y lea los
casos de uso? ¿Qué aspectos pueden motivarlos a participar más de esta
tarea?
¿Y qué podemos hacer para introducir estos incentivos en nuestro proceso de construcción de software?
Autor de la discusión: Luis Antonio
Salazar Caraballo – Consultor Senior en Metodologías y Arquitectura de
Software – Colombia (acceso al perfil público en linkedin)
Algunos comentarios dejados por los miembros del grupo:
Comentario 1
La motivación para leer un caso de uso viene siempre por el interés del usuario de conocer cierta funcionalidad del sistema. Luego el caso de uso debe estar lo suficientemente claro y simple para que sirva de medio de comunicación entre los participantes del proyecto.
La motivación para leer un caso de uso viene siempre por el interés del usuario de conocer cierta funcionalidad del sistema. Luego el caso de uso debe estar lo suficientemente claro y simple para que sirva de medio de comunicación entre los participantes del proyecto.
Comentario 2
Depende desde que empiezas a definir cual será tu caso de uso y su enfoque, muchas veces un solo caso de uso puede ser tan extenso, detallado, y ademas rebuscado, que es difícil que nuestros usuarios puedan entenderlo.
Depende desde que empiezas a definir cual será tu caso de uso y su enfoque, muchas veces un solo caso de uso puede ser tan extenso, detallado, y ademas rebuscado, que es difícil que nuestros usuarios puedan entenderlo.
Comentario del Autor
Maximiliano, lo que ocurre es que siempre damos por hecho que las demás personas están motivadas en el proyecto y muchas veces tenemos que darles un “empujoncito”, ayudarlos a “meterse al agua”. Y aunque son dos aspectos importantes de motivación, la claridad y la simplicidad son dos atributos difíciles de lograr, sobre todo, si no tenemos la experiencia suficiente como escritores técnicos, cosa usual en los Analistas Funcionales. En este sentido, una presentación formal de los casos de uso ayuda antes de dejárselos para su lectura.
Maximiliano, lo que ocurre es que siempre damos por hecho que las demás personas están motivadas en el proyecto y muchas veces tenemos que darles un “empujoncito”, ayudarlos a “meterse al agua”. Y aunque son dos aspectos importantes de motivación, la claridad y la simplicidad son dos atributos difíciles de lograr, sobre todo, si no tenemos la experiencia suficiente como escritores técnicos, cosa usual en los Analistas Funcionales. En este sentido, una presentación formal de los casos de uso ayuda antes de dejárselos para su lectura.
Comentario del Autor
Norma, lo ideal es que los casos de uso nunca sean “tan” extensos ni rebuscados. Cuando esto ocurre quizás nos encontramos antes más de un caso de uso y es allí donde los usuarios se confunden. En este sentido, los casos de uso deben ser indivisibles, en el sentido de “especializados”. Es decir, deben representar una funcionalidad simple para el actor, para el usuario.
Norma, lo ideal es que los casos de uso nunca sean “tan” extensos ni rebuscados. Cuando esto ocurre quizás nos encontramos antes más de un caso de uso y es allí donde los usuarios se confunden. En este sentido, los casos de uso deben ser indivisibles, en el sentido de “especializados”. Es decir, deben representar una funcionalidad simple para el actor, para el usuario.
Comentario 3
Sin dudas el usuario tiene que estar comprometido desde el principio con la generación y validación de la documentación funcional. Eso generalmente viene condicionado por un entorno de negocio en donde nosotros no solemos tener injerencia.
Pero en donde sí tenemos injerencia es en el formato y contenido de la documentación que confeccionamos. En este sentido nunca debemos olvidar que lo más importante es que los usuarios comprendan correctamente las características del producto que las personas de IT están por crear. Tenemos todo un arsenal de herramientas a nuestro alcance: prototipos de interfaz de usuario, narrativas desestructuradas, planillas de cálculo o los diversos diagramas UML.
Por supuesto, no tenemos que incluir detalles técnicos como consultas SQL por ejemplo. Pero es imperativo que incluyamos las funcionalidades COMPLETAS. Esto es, no se debe omitir detalles funcionales solo para hacer más simple una especificación. Si el dominio del problema es complejo, la especificación será cuanto menos igual de compleja. De lo contrario nos estamos dejando algo en el tintero. Por ejemplo, si estamos especificando una consulta de clientes por pantalla, detalles como la forma en que los datos van a estar ordenados y los filtros que podrán ser usados son sumamente importantes, porque afectan a la usabilidad final de la aplicación. Entonces no podemos obviarlos con el pretexto de que son datos “muy técnicos” o que extienden demasiado las especificaciones y dejarlos de lado así nada más. Porque tarde o temprano, alguien va a tomar una decisión con respecto a esas cuestiones que no quedaron bien definidas y en esa instancia ya el usuario ni siquiera va a ser consultado sobre el asunto.
Sin dudas el usuario tiene que estar comprometido desde el principio con la generación y validación de la documentación funcional. Eso generalmente viene condicionado por un entorno de negocio en donde nosotros no solemos tener injerencia.
Pero en donde sí tenemos injerencia es en el formato y contenido de la documentación que confeccionamos. En este sentido nunca debemos olvidar que lo más importante es que los usuarios comprendan correctamente las características del producto que las personas de IT están por crear. Tenemos todo un arsenal de herramientas a nuestro alcance: prototipos de interfaz de usuario, narrativas desestructuradas, planillas de cálculo o los diversos diagramas UML.
Por supuesto, no tenemos que incluir detalles técnicos como consultas SQL por ejemplo. Pero es imperativo que incluyamos las funcionalidades COMPLETAS. Esto es, no se debe omitir detalles funcionales solo para hacer más simple una especificación. Si el dominio del problema es complejo, la especificación será cuanto menos igual de compleja. De lo contrario nos estamos dejando algo en el tintero. Por ejemplo, si estamos especificando una consulta de clientes por pantalla, detalles como la forma en que los datos van a estar ordenados y los filtros que podrán ser usados son sumamente importantes, porque afectan a la usabilidad final de la aplicación. Entonces no podemos obviarlos con el pretexto de que son datos “muy técnicos” o que extienden demasiado las especificaciones y dejarlos de lado así nada más. Porque tarde o temprano, alguien va a tomar una decisión con respecto a esas cuestiones que no quedaron bien definidas y en esa instancia ya el usuario ni siquiera va a ser consultado sobre el asunto.
Comentario 4
Comparto mucho con las opiniones vertidas. Como se señala con anterioridad, influye directamente la forma de realizar la documentación para que esta sea de rápida aprobación por el usuario o se tarde más en analizarla y comprenderla.
No debemos olvidar que una documentación sencilla y simple no es sinónimo de malo o ambiguo.
Una gran carácteristica de un buen analista es interpretar de manera sencilla, ágil y en el lenguaje del cliente sus requerimientos.
Además, desde mi perspectiva una motivación importante para un stakeholder en la revisión de los Casos de Uso es hacerlo participe, hacerlo sentir que el Caso de Uso es producto de su conocimiento sobre el negocio.
Comparto mucho con las opiniones vertidas. Como se señala con anterioridad, influye directamente la forma de realizar la documentación para que esta sea de rápida aprobación por el usuario o se tarde más en analizarla y comprenderla.
No debemos olvidar que una documentación sencilla y simple no es sinónimo de malo o ambiguo.
Una gran carácteristica de un buen analista es interpretar de manera sencilla, ágil y en el lenguaje del cliente sus requerimientos.
Además, desde mi perspectiva una motivación importante para un stakeholder en la revisión de los Casos de Uso es hacerlo participe, hacerlo sentir que el Caso de Uso es producto de su conocimiento sobre el negocio.
Comentario del Autor
Germán, para lograr lo que dices es necesario involucrar, en el sentido de “hacer que se interese”, al usuario desde el comienzo hasta el final del proyecto. No debe haber ningún instante durante el ciclo de vida en que dejemos que el usuario se distraiga. El enfoque iterativo nos da pistas sobre cómo podemos alcanzar esta meta. Además de lo que mencionas, están los tableros de historias (storyboards), simuladores, proyecciones, prototipos funcionales y no funcionales, escenarios, los casos de prueba. Pero se necesita integrar al usuario al ADN del proyecto, como parte imperativa del equipo. Acaso sean necesarias sesiones de estimulación para trabajo en equipo, sesiones de “terapia” de cómo juntos todos podemos lograr más que separados y cosas de esas.
Germán, para lograr lo que dices es necesario involucrar, en el sentido de “hacer que se interese”, al usuario desde el comienzo hasta el final del proyecto. No debe haber ningún instante durante el ciclo de vida en que dejemos que el usuario se distraiga. El enfoque iterativo nos da pistas sobre cómo podemos alcanzar esta meta. Además de lo que mencionas, están los tableros de historias (storyboards), simuladores, proyecciones, prototipos funcionales y no funcionales, escenarios, los casos de prueba. Pero se necesita integrar al usuario al ADN del proyecto, como parte imperativa del equipo. Acaso sean necesarias sesiones de estimulación para trabajo en equipo, sesiones de “terapia” de cómo juntos todos podemos lograr más que separados y cosas de esas.
Comentario 5
Hola Luís Antonio.
Hola Luís Antonio.
A decir verdad, hacia los usuarios nunca
utilizo el término ‘caso de uso’, ya que este término es tecnológico;
así como los es el término ‘usuario’.
Yo evito que ‘mis usuarios’ lean los
‘casos de uso’ del sistema. Si el objetivo es que ‘mis usuarios’
comprendan perfectamente qué hará el sistema, a mí siempre me ha
funcionado las exposiciones, donde se explica (1) el objetivo del
proceso del negocio particular; (2) lo que integrará, automatizará y
dará inteligencia el sistema el proceso del negocio, ilustrados con
diagramas de flujo; (3) los resultados que el sistema debe generar; y,
(4) la ejecución de todos los casos prácticos, o casuística, del proceso
del negocio haciendo análisis de resultados.
Antes de continuar, quiero aclarar que
yo no utilizo los términos ‘usuarios’ y ‘casos de uso’; en vez de esos
utilizo los términos ‘ejecutivos del negocio’ y ‘procesos del negocio’.
Inclusive, cuando tengo que hacer la misma exposición con el equipo de
desarrollo también utilizo los términos ‘ejecutivos del negocio’ y
‘procesos del negocio’. En otra oportunidad, si me lo permiten, expondré
mis argumentos por el uso de estos términos.
Los ejecutivos del negocio realmente se
sientes motivados en las exposiciones, ya que se sienten muy
entusiasmados al ejecutar sus casuísticas en los flujos propuestos para
el sistema, y siempre están con los cuadernos y apuntes haciendo sus
análisis de resultados. Esta práctica sirve de mucho en las expectativas
del futuro sistema.
Además, siempre termino satisfecho al
término de cada exposición cuando los ejecutivos del negocio se dan
cuenta de cuán rentable será la solución respecto a cuánto cuesta ahora
el proceso del negocio. Los negocios siempre están buscando la
rentabilización con sus soluciones, sea para aumentar sus ingresos o
para reducir sus costos de operaciones.
Comentario del Autor
Gerardo,
Gerardo,
Interesante tu enfoque de “ejecutivos
del negocio” y “procesos del negocio”, sin embargo, sobre esta última
expresión, ¿cómo distingues entonces un “proceso de negocio”, es decir,
algo que ocurre en el negocio con o sin el “apoyo” de herramientas
automatizadas”, y “procesos del sistema”, es decir, algo que ocurre
puramente en un sistema de software?
Acuerdo contigo en lo que tiene que ver
con la exposición a los usuarios o ejecutivos del negocio, como los
llamas. Es una excelente práctica y normalmente arroja muy buenos
resultados. En cualquier caso, los requisitos (expresados como casos de
uso o no), nunca deben ser enviados al usuario “en frío”, siempre viene
bien una reunión, o varias, de presentación de todos estos requisitos,
una reunión bien ambientada, donde todas las partes estén motivadas,
conozcan bien el objetivo de la sesión y que se den los debates a que
haya lugar para que al final todos salgamos con la misma Visión, ese es
precisamente el objetivo final, que haya consenso entre todos los
interesados sobre lo que hará y no hará el sistema.
Escuchamos atento tu aproximación de “ejecutivos de usuario” y “procesos del negocio”.
Comentario 6
Luis, yo tengo la firme convicción de que si el usuario no se hace partícipe de la elaboración de los casos de uso estos no terminan sirviendo para nada, recordemos que estos son esenciales como materia prima de todo lo que se hará de ahí en adelante y como elemento que permite validar si el software si cumplió con el alcance.
Luis, yo tengo la firme convicción de que si el usuario no se hace partícipe de la elaboración de los casos de uso estos no terminan sirviendo para nada, recordemos que estos son esenciales como materia prima de todo lo que se hará de ahí en adelante y como elemento que permite validar si el software si cumplió con el alcance.
Evidentemente, lo difícil es hacer que
el usuario se involucre, para esto lo que hago es dejarle bien claro al
usuario que el caso de uso será el elemento con el que al momento de
hacer la entrega el podrá validar si lo que se le está entregando es lo
que él acordó con el equipo de desarrollo.
Para esto, de forma coloquial, les relato lo que yo hago:
Hago una lista de todos los “deseos” que el usuario tienen para con el sistema,
A partir de estos elaboro un modelo de
casos de uso que cubran todos los deseos que el usuario planteó en un
principio, si es del caso se deja evidencia que algunos de estos
“deseos” no serán cubiertos,
Este modelo se lo presento al usuario y
con él procedo a recorrer la lista de deseos y que en conjunto deje
registro cual o cuales casos de uso cubren cada uno de sus deseos
(trazabilidad), evidentemente yo tengo previamente dicha trazabilidad,
pero dejo que el usuario participe de dicho ejercicio y así este termina
conociendo el entorno en que van a “vivir” los casos de uso que
posteriormente van a ser detallados en conjunto con él.
Con este modelo de casos de uso
validados me “encierro” a agrupar y ordenar dichos grupos de modo tal
que pueda desarrollar el detalle de cada grupo incrementalmente. Aquí
quedan medianamente definidas la iteraciones en lo que tiene que ver con
la disciplina de requisitos, si el proyecto involucra las demás
disciplinas entonces valido con los líderes de todas estas la
pertinencia de dichos grupos.
De aquí en adelante hago lo mismo con cada grupo de casos de uso:
Planeo una reunión con el usuario para
recibir el detalle necesario para desarrollar el conjunto de casos de
uso. Para esto le envío previamente la porción del modelo a analizar y
un conjunto de preguntas al respecto. Mientras yo preparo a partir de
los documentos de que disponga material para ilustrar al usuario
respecto al alcance de cada caso de uso del grupo.
En la reunión pregunto al usuario sobre
los detalles respecto al conjunto de casos de uso, presento un diseño de
pantalla tentativo, si es del caso elaboro un prototipo con los
elementos esenciales. En esta reunión llego a acuerdos con este respecto
a cada uno de los elementos que constituyen cada caso de uso, cuales
son los flujos básicos y alternos, restricciones, elementos esenciales
de pantalla, subsistemas involucrados, necesidades que quedaran por
fuera de la solución o que serán implementadas en otro(s) caso de uso…
Con la información recopilada en la
reunión, elaboro el detalle de cada caso de uso, hago el diseño
detallado de pantallas, defino la trazabilidad entre los “deseos” y los
casos de uso y hago una validación de viabilidad con el resto del equipo
de desarrollo respecto al alcance.
Una vez tengo el detalle le envío la documentación al usuario para que la analice y presente sus observaciones al respecto
Una vez tengo retroalimentación del
usuario lo cito para presentarle el grupo de casos de uso en detalle y
así poder aclarar las dudas y obtener el visto bueno de este para pasar a
la siguiente etapa del desarrollo. Aquí viene la frase “cualquier
cambio en este conjunto de casos de uso, de aquí en adelante, conlleva
el levantamiento de un control de cambios”.
Así en cada etapa del proceso involucro
al usuario, pero dejando claro, que este debe obtener para poder
involucrarse la visión del “conjunto” y del “detalle” del modelo, además
que este es documento que define el acuerdo entre él y el equipo de
desarrollo.
Quedo atento a sus observaciones respecto a mis tácticas para “motivar” al usuario.
Comentario 7
Hola José García,
Acabo de leer tu comentario sobre este
debate, y déjame compartir que coincido contigo cuando dices: “Hago una
lista de todos los “deseos” que el usuario tienen para con el sistema…”.
Sin embargo, permíteme iniciar un debate contigo, y con quienes apoyan
tu argumento y con los que apoyarían el mío; y es cuando afirmas: “…
tengo la firme convicción de que si el usuario no se hace partícipe de
la elaboración de los casos de uso estos no terminan sirviendo para
nada, recordemos que estos son esenciales como materia prima de todo lo
que se hará de ahí en adelante y como elemento que permite validar si el
software si cumplió con el alcance…”
Importante: Pido por favor, a
experiencia propia en debates, aquí en LinkedIn, que se tome los
comentarios, fundamentos, argumentos, discrepantes como un aporte a la
discusión o debate sobre un tema. Ya que en varias oportunidades dichas
discrepancias muchos lo toman a modo personal o de ‘ataque’. Sería
genial que en este grupo y en este en tema, en particular, las cosas
sean alturadas y profesionales.
Empiezo con lo primero. Me encanta, al
igual que a José García, invitar a los ejecutivos del negocio a que
visionen su solución ideal. Inclusive, me gusta ampliar o aportar ideas
nuevas sobre sus ideales. Me fascina ver los ojos brillosos de aquellos
ejecutivos cuando les dices que sí se puede hacer lo que ellos desean.
Claro que todo con suma cordura y con
los pies bien puestos sobre la tierra. Siempre acomodo los deseos de los
ejecutivos del negocio, sobre su futura solución, a lo que uno, como
especialista en soluciones de negocio, puede hacer por ellos. Siempre
aterrizo sus ideas en situaciones reales; pero siempre acompañando el
sueño de los ejecutivos del negocio.
Como experiencia les cuento que uno de
mis últimos proyectos, me invitaron a una convocatoria a participar en
una propuesta de solución. El negocio tenía un proceso muy caro; además,
era un proceso distintivo del negocio (core_business). En cifras
redondeadas, el proceso costaba cerca de un mes y medio en realizarlo,
con más de 10 personas involucradas. Si hacemos una multiplicación
simple, el proceso era muy costoso. Por otro lado, solo se podía hacer
un proceso a la vez. Los especialistas en proceso de negocio hicieron un
análisis, y prepararon un documento de alcance, donde, principalmente,
tenían como objetivo reducir ese tiempo a la mitad; es decir, más o
menos a dos semanas, haciendo re-ingeniería y simplificación de
procesos.
Cuando nos tocó a nosotros, y con la
modestia que corresponde, quien les escribe lideró dicho proyecto. Luego
de que la analista de procesos del negocio hizo su exposición sobre la
situación actual y de la solución que ellos habían concluido, pues me
puse súper atrevido con las ideas y aportes. Recuerdo con mucho agrado
cuando les decía: “… para soluciones este problema en particular, yo les
propongo tal solución…”, luego continué con: “… y para este problema
específico, recomendamos esta solución…”. Y así, continué con más
aportes a la iniciativa de solución de ellos.
Luego me vi sorprendido con las
siguientes preguntas de los ejecutivos del negocio: “… Gerardo, ¿y se
puede hacer esto, y lo otro?”, y lo les respondía, con los pies sobre la
tierra: “… por supuesto; inclusive, podríamos hacer esto, y además este
otro…”. Lo cierto es que los ejecutivos de negocio quedaron
estupefactos con las soluciones que nosotros ofreceríamos como valor
agregado a la alternativa de solución que ellos habían determinado.
¡Ha! Pero no todo fue de color de rosas.
Los ejecutivos de negocio, a las iniciativas nuestras, de muy
optimistas con nuestras soluciones, nos pidieron un prototipo
demostrando que todo los que nosotros ofrecíamos era cierto. Y así fue. A
los dos días, volvimos a visitarlos con nuestro prototipo, y ellos
quedaron más que entusiasmados con los resultados.
El beneficio de toda esta pro-actividad
en propuestas de solución d negocios, el cliente de sistemas nos
adjudicaron el proyecto. Al pasar los meses que duró el desarrollo,
ahora el negocio cuenta con una solución de que no solo logró reducir
los tiempos a la mitad del tiempo; sino que se logró reducir el tiempo
de, proceso del negocio en un promedio de 10 minutos, sobre el mes y
medio que les tomaba a ellos hasta entonces.
Con esta experiencia quiero corroborar
que los negocio no necesariamente tienen la solución ideal en el
documento de alcance que ellos elaboran; sino que es muy importante la
habilidad, la experiencia y, principalmente, la creatividad que podemos
tener al momento de replantear las alternativas de soluciones con otras
mucho mejores.
Sin embargo, discrepo con José García
cuando afirma que los usuarios (finales) (ejecutivos del negocio) son
esenciales como materia prima para solución. Como siempre digo: “Los
usuarios no siempre tienen la razón.”. Y la explicación, en base a la
experiencia, es bastante simple. Y aquí otra anécdota.
Antes de compartir mi experiencia, debe
recordar, o recalcar, la razón de ser de las tecnologías de información
en los negocio. Todo negocio, con fines de lucro, siempre están en la
constante búsqueda de la rentabilización de sus procesos. Es decir,
reducir los costos y aumentar los ingresos. Y las tecnologías de
información son un pilar para este objetivo.
Una vez me tocó automatizar un proceso
de un negocio. Utilicé, cuando era aún muy joven en esta profesión, el
tradicional método de entrevistar a los usuarios finales (ejecutivos del
negocio) para ‘levantar información’, y a partir de eso diseñar la
solución.
Lo cierto es que los usuarios nunca
tenían la visión del negocio. Dichos ‘usuarios finales’ solo requerían
que los sistemas tengan lo que a ellos les parecía ventajoso para el
negocio. Es decir, pedían muchos reportes con indicadores de gestión y
de análisis, pero eran reportes que ellos les habían enseñado en las
escuelas. Pero ninguno de aquellos reportes estaban vinculados con la
estrategia del negocio: Menos costos, y más ingresos. Simplemente, cada
gerente y jefatura, hacían sus requerimientos como a ellos mejor les
parecía.
Está claro que en esta oportunidad, al
negocio le faltaba mucha integración de sus objetivos gerenciales con
los del negocio, pero así funcionaba este negocio, y así funciona muchos
de los negocios también.
Al final, terminé diseñando una solución
que no aportaba ningún valor al negocio. A pesar que estaban
estrictamente a la medida de los ejecutivos del negocio. Y dicho sea
verdad, ´nunca generó valor el sistema al negocio, ya que, al contrario,
generó sobre costos al negocio, ya que se requería invertir en
infraestructura tecnológica, contratar más personal.
Esta experiencia me enseñó que los
usuarios finales no siempre tienen la razón. Y para sortear esto, y ser
más efectivos en nuestra propuesta de solución, debemos conocer mucho
más el negocio y su modelo, sin necesidad de entrar en la dependencia de
los ejecutivos del negocio del momento.
A partir de esa experiencia, antes de
tener mi primera entrevista con mi cliente de sistemas, averiguo
exhaustivamente sobre su modelo de negocio. Consulto con colegas y
amistades profesionales sobre los problemas típicos que tienen ese tipo
de negocio, planteamos las posibles soluciones, y finalmente llego a esa
primera entrevista con una solución ideal sobre ese negocio. El
beneficio de este ejercicio es el caso de la primera anécdota que les
mencioné en la segunda parte de mi comentario.
Comentario 8
Si algo tengo claro es que a la hora de “modelar una solución” el usuario, cliente, stakeholder… casi nunca tiene la razón, para eso están los analistas funcionales o arquitectos funcionales. Para soportar esta afirmación tengo múltiples anécdotas que algún día les contaré.
Si algo tengo claro es que a la hora de “modelar una solución” el usuario, cliente, stakeholder… casi nunca tiene la razón, para eso están los analistas funcionales o arquitectos funcionales. Para soportar esta afirmación tengo múltiples anécdotas que algún día les contaré.
Pero este modelo debe ser presentado a
los usuarios para poder validar su alcance, para que este pueda
posteriormente tener claro el marco en que funcionan las diferentes
opciones de la solución.
Hay que tener cuidado con validarlo
contra “lo que el sistema debe hacer”, no dejarse llevar por el usuario
hacia “como el sistema lo debe hacer”, y esa es una de las competencias
que se debe tener: expresar los deseos del cliente en términos de lo que
el sistema debe hacer, sobre los objetivos del sistema, no sobre como
el sistema debe implementar estos deseos. Así es posible ser creativo al
momento de modelar y se hace factible la validación de los deseos.
El asunto es, ¿cómo expresar el modelo
que enmarca la solución?, yo lo plasmo en un modelo de casos de uso +
modelo de clases, para poder posteriormente hacer un seguimiento
detallado del alcance planteado al usuario (cronograma, tiempos,
esfuerzos, funcionalidad…), no he encontrado otra herramienta más
adecuada que los casos de uso. En un punto no son más que la descripción
del alcance de cada uno y posteriormente se detalla cada uno de estos,
en este proceso es que el usuario debe participar, validando el alcance,
definiendo las características de los campos que se incluyen en cada
especificación de pantalla.
Con esto se garantiza que las
expectativas del usuario con respecto al sistema son formales, que no se
tengan ambigüedades, para que al momento de hacer entrega no se
presenten malos entendidos.
Comentario 9
De acuerdo contigo con los primeros
argumentos, José García. Respecto a lo segundo, que utilizas casos de
uso y modelos de clases, allí hago una excepción, ya que son documentos
(en las formas) más tecnologías o proyectos, que lenguaje de negocio. En
ese caso, cuando tengo que presentar a los usuarios (ejecutivos de
negocio) las propuestas, siempre trato de hacerlo con leguaje e
ilustraciones de negocio, como diagramas de flujos; ya que los otros no
comprenden. Ellos (ejecutivos de negocio) ven a su negocio como un flujo
de información, donde ven procesos, documentos, datos, cálculos,
reportes, reglas del negocio, etcétera. Los casos de uso son
ilustraciones más técnicas (de tecnología) que de negocio. Los modelos o
diagramas de clases son más de arquitectura, que de negocio. Y lo más
importante es que los ejecutivos del negocio comprendan de una mejor
forma lo que su futuro sistema hará por ellos. Otra alternativa son los
diagramas de dominio, que contienen elementos de casos de uso más flujos
de procesos.
http://testingbaires.com/debate-motivacion-para-lectura-de-casos-de-uso/
No hay comentarios.:
Publicar un comentario