Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: XI

"Los buenos consejos no son tomados en cuenta generalmente, pero eso no es motivo para no darlos."

Agatha Christie

Consejo Adicional: ¿Cómo luce un caso de uso inefectivo?

Caso de Uso: Apertura de Productos y Servicios

Secuencia Básica:

1.     Muestre una lista de productos y servicios de la siguiente forma:

•         La ventana izquierda lista todas las categorías de productos y servicios de la compañía (Ahorro e Inversión, Crédito Hipotecario, Otros Créditos)
•         La ventana inferior muestra los datos que se solicitan para el producto seleccionado
•         La tercera ventana muestra todos los productos y servicios que tiene actualmente el cliente

2.     Haga:

3.     El usuario hace clic en una categoría de producto o servicio

4.     Muestre los productos disponibles en esa categoría en orden alfabético

5.     El usuario hace clic en un producto

6.     Se actualiza la ventana inferior para solicitar los datos necesarios para la apertura del producto y el usuario hace clic en el botón “Solicitar Producto”.

7.     Chequee si el usuario cumple los requisitos necesarios para solicitar ese producto y que el producto esté disponible para su “tipo de persona” (Natural o Jurídica)

8.     Si el producto está disponible y el usuario cumple los requisitos necesarios, adicione el producto al usuario. Muestre la lista actualizada de productos del usuario, con el nuevo producto en estado “Solicitado”. Si no, muestre el mensaje “El cliente no cumple los requisitos necesarios. Seleccione otro producto.”

9.     Repita desde 3 hasta que el usuario haga clic en “Terminar Solicitud”

10.   Almacene la solicitud y regrese a la pantalla principal.

¿Y cómo luce un caso de uso efectivo?

Caso de Uso: Solicitar Producto

Actor: Cliente

Secuencia Básica:

1.     El Cliente solicita abrir un producto

2.     El sistema muestra la lista de productos actuales del cliente y muestra una lista de productos disponibles

3.     El Cliente selecciona el producto a solicitar

4.     El sistema verifica que el Cliente cumple con los requisitos necesarios y adiciona el producto a la lista de productos del cliente, en estado “Solicitado”.

5.     El sistema almacena la solicitud

Veamos algunos aspectos importantes de estas dos versiones:

Versión Inefectiva	Versión Efectiva
El nombre del caso de uso no es apropiado	El nombre está escrito como una frase verbal simple (en el formato “hacer algo”)
No tiene un actor definido	Tiene un actor principal, el Cliente.
El caso de uso se refiere a “el usuario” como actor del mismo. “Usuario” no es un concepto formal, es un humano, puede actuar como diferentes instancias de varios actores distintos.	El caso de uso se refiere a “el cliente” como actor del mismo. “Actor” es un concepto formal, puede ser un humano o un sistema, existe sólo si un usuario hace algo.
Está escrita en una especie de pseudocódigo y en lenguaje técnico.	Está escrita en prosa
Relaciona muchos aspectos de la interfaz de usuario. Orientado al Sistema.	Está escrito en términos del negocio (del usuario). Orientado al Negocio.
Aborda elementos que pueden ser disímiles en su tratamiento (productos y servicios, categorías de productos)	Aborda sólo productos. Incluso, los casos de uso deberían especificarse para un único producto a la vez.
Algunos pasos son complejos, difíciles de leer o muy largos. (Pasos 1 y 8).	Los pasos son claros, en el formato “el sistema hace…el actor hace”
La secuencia básica parece abarcar todos los escenarios posibles del caso de uso	La secuencia básica deja muchos escenarios para secuencias alternativas, como la solicitud de servicios o cuando el cliente no cumpla con las condiciones exigidas.
Parece haber sido especificado por completo en una sola pasada.	Le faltan detalles, pero estimula la creación iterativa de casos de uso.
Algunos pasos describen acciones consecutivas ejecutadas por el sistema y por el usuario a la vez.	Todos los pasos están escritos como expresiones verbales simples.

El verdadero truco con los casos de uso es mantenerlos simples. No nos preocupemos acerca de las formas del caso de uso, solo procuremos garabatearlos en una hoja de papel en blanco o en una página en blanco de un procesador de palabras simple, o en unas tarjetas indexadas blancas. No nos preocupemos por cubrir todos los detalles de inmediato. Los detalles no son importantes hasta mucho después. No nos preocupemos por capturar todos los casos de uso desde el principio; esa es una tarea imposible.

La única cosa para recordar sobre casos de uso es: mañana van a cambiar. Sin importar que tan diligente seamos a la hora de capturarlos, sin importar que tan meticulosamente registremos los detalles, sin importar que tan sistemáticamente pensemos acerca de los casos de uso, sin importar el mucho esfuerzo que hagamos para explorar y analizar los requisitos, mañana los casos de uso cambiarán.

Después vendrán las herramientas sofisticadas de apoyo. Las herramientas aumentan nuestra productividad, nos ayudan a clasificar, a buscar, a estimar, pero no hacen el trabajo por nosotros.

Esta es una visión minimalista del proceso, algunos la llaman ágil. Simplemente es una manera de hacer las cosas, una manera efectiva en ciertos casos. Ese es el verdadero sentido de esto: para cada proyecto, para cada actividad, debemos buscar o construir el mejor camino para ir de principio a fin y entregar el mejor de los resultados, el único posible.

W953BAF3WB56

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: X

Consejo 10

No usemos expresiones del tipo: “el sistema verifica si se cumple tal condición” y más adelante: “si se cumple la condición, haga esto”, y para terminar: “si no se cumple la condición, haga esto otro.” Este es un patrón que viene de la programación de computadores, es más bien pseudocódigo y la primera de las acciones no cumple con una de las premisas importantes de un caso de uso y es que cada acción lleve la secuencia del caso de uso un paso más adelante que el anterior. Vemos claramente que “el sistema verifica si se cumple tal condición” no avanza en el proceso, en cambio, debemos esperar hasta la siguiente operación: “si se cumple…” para continuar la secuencia.

En cambio, escribamos el caso de uso en términos de escenarios:

n. El sistema verifica que tal condición se cumple y hace…

n+1. El actor hace…

En una secuencia alterna especificamos lo que ocurre cuando la condición no se cumple:

nA1. El sistema verifica que tal condición no se cumple y hace…

(n+1)A2. El actor hace…

Como en:

4. El sistema verifica que el Cliente tiene capacidad de endeudamiento y solicita el valor del crédito

5. El actor ingresa el valor del crédito

Y en la secuencia alterna:

4A1. El sistema verifica que el Cliente no tiene capacidad de endeudamiento y solicita la identificación del avalista

4A2. El actor ingresa la identificación del avalista

Ejemplo

Consideremos este fragmento de caso de uso para verificar los fondos de una cuenta bancaria con miras a hacer efectivo un cheque.

Caso de Uso: Verificar fondos cuenta

Actor: Cajero

Secuencia Básica:

1.     El caso de uso inicia cuando el Cajero decide verificar los fondos disponibles para un cheque

2.     El sistema solicita el tipo y número de cuenta

3.     El Cajero ingresa el tipo y número de cuenta

4.     El sistema verifica que el número de cuenta existe y que está Activa y solicita el número del cheque

5.     El cajero ingresa el número del cheque

6.     El sistema valida que el número del cheque está dentro del rango autorizado y que no está contraordenado, y solicita el valor del cheque

7.     El cajero ingresa el valor del cheque

8.     El sistema verifica que hay fondos suficientes para pagar el cheque

9.     El caso de uso termina

Secuencia Alterna 1:

4A. El número de cuenta no existe

4A.1. El sistema verifica que el número de cuenta no existe y muestra el mensaje: “El número de cuenta dado no existe. Verifique.”

4A.2. El caso de uso continúa en el paso 2 de la secuencia básica.

Secuencia Alterna 2:

6A. El número del cheque no está dentro del rango autorizado

6A.1. El sistema verifica que el número del cheque no está dentro del rango autorizado y muestra el mensaje “El número del cheque no está autorizado. Verifique.”

6A.2. El caso de uso continúa en el paso 5 de la secuencia básica

Secuencia Alterna 3:

8A. No hay fondos suficientes para pagar el cheque

8A.1. El sistema verifica que la cuenta no tiene fondos suficientes para pagar el cheque y muestra el mensaje “Fondos insuficientes. Verifique.”

8A.2. El caso de uso continúa en el paso 7 de la secuencia básica

La escritura limpia del caso de uso lo hace claro, preciso y consistente, entre otros atributos deseables en un caso de uso. Nótese que es posible que haya más secuencias alternas.

Para saber más de casos de uso pueden visitar la sección Lecturas Fundamentales de mi Gazafatonario IT. En particular, pueden leer la Lectura Fundamental 3: Casos de Uso: Del Todo y de sus Partes.

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

Esta serie de consejos útiles para escribir casos de uso inicia en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos: VIII y IX

Consejo 8

Cuando se trata de incluir casos de uso se escribe:

• El sistema ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

O simplemente,

• Se ejecuta el caso de uso “AQUÍ VIENE EL NOMBRE DEL CASO DE USO INCLUIDO”

En este último caso se entiende que el único que ejecuta casos de uso incluidos es el sistema. Como en:

n. El sistema ejecuta el caso de uso “Verificar Lista Clinton”

n+1. Se ejecuta el caso de uso “Hacer Análisis de Riesgo”

Consejo 9

La especificación de un caso de uso incluido se debe iniciar estableciendo los nombres de los casos de uso que incluyen este caso de uso, como en:

1.     Este caso de uso se incluye en los casos de uso:

        a.     Caso de uso base 1

        b.     Caso de uso base 2

        c.     …

        d.     Caso de uso base n

2.     El sistema hace…

3.     El actor hace…

…

n. El caso de uso termina

Donde n es el número del último paso del caso de uso incluido.

Recordemos que esta relación de inclusión se usa cuando queremos:

•      Factorizar o descomponer (en sentido matemático) el comportamiento del caso de uso base que no es necesario para entender el objetivo principal del mismo y donde solamente el resultado del caso de uso incluido es importante.
•      Distribuir en uno o más casos de uso, funcionalidad del caso de uso base que es común para dos o más casos de uso (reusabilidad).

La primera opción se usa especialmente en casos de uso largos o complejos donde algunas partes del mismo no son relevantes para el sentido primordial del caso de uso y no son necesarias, en primera instancia, para entenderlo y aprobarlo. Por ejemplo, un caso de uso para Ingresar un Cliente de Naturaleza Jurídica puede solicitar docenas o cientos de datos que se pueden agrupar de acuerdo a algunos criterios como Datos Generales, Datos del Tipo de Entidad y Naturaleza Jurídica, Datos del Gerente o Representante Legal, Datos de los Contactos, Referencias Comerciales, entre otros. Algunos de estos grupos de datos pueden incluirse en casos de uso complementarios que son ejecutados desde el caso de uso principal.

La segunda posibilidad de inclusión es la reusabilidad de funcionalidad del sistema, es decir, cuando existe un comportamiento del sistema que se ejecuta en dos o más casos de uso de la misma manera, podemos usar un caso de uso incluido que represente ese comportamiento común. Por ejemplo, un caso de uso Verificar Centrales de Riesgo, que se ejecuta desde varios casos de uso de un sistema financiero, como Matricular Cliente, Revisar Solicitud de Crédito, Abrir Cuenta Corriente, entre otros.

Para conocer más acerca de relaciones entre casos de uso, pueden leer la Lectura Fundamental 12 Casos de Uso: de Extensiones y de Inclusiones en mi Gazafatonario IT:

http://www.gazafatonarioit.com/2008/05/lectura-fundamental-12-lectura_8835.html

La serie completa de estos consejos la encuentran en:

http://www.gazafatonarioit.com/2012/10/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_4.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_6.html

http://www.gazafatonarioit.com/2012/11/diez-consejos-utiles-y-simples-para_8.html

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, II

Siempre que sea posible, debemos evitar secuencias de pasos como:

n. El sistema hace…

n+1. El sistema hace…

O

m. El actor hace…

m+1. El actor hace…

Donde n y m son números de pasos de una secuencia cualquiera del caso de uso. Es decir, ni el sistema ni el actor ejecutan dos pasos seguidos en el caso de uso. La escritura de casos de uso debe (ría) obedecer al siguiente patrón de diálogo:

p. El sistema hace…

p+1. El actor hace…

Donde “hace” se debe reemplazar por la acción que uno y otro ente realizan. Normalmente, el sistema “solicita” el ingreso o selección de datos y el actor “proporciona” datos, ya sea ingresándolos (por medio del teclado, en cuyo caso “digita” los datos) o seleccionando uno o más datos disponibles de una lista suministrada por el sistema. Nunca se debe especificar el mecanismo programático (formularios, ventanas, cuadros de texto, listas combinadas, cuadros de chequeo, botones de comando, entre otros) utilizado para crear y mostrar la lista. Ejecutar.

Además, nuestros usuarios siempre esperan que los sorprendamos con algo novedoso y una forma mejor de hacer las cosas. En el futuro cercano, por ejemplo, esperarían no tener que lidiar con la clásica interfaz gráfica de hoy sino con hologramas u otra suerte de mecanismos de comunicación Humano-Máquina. Pero ese es otro asunto.

Volviendo al consejo práctico que nos ocupa, normalmente cuando ocurre que debemos especificar varias actividades seguidas de un actor o del sistema, nos encontramos ante una de estas situaciones: estamos haciendo descomposición funcional que, en principio, es innecesaria. Recordemos que lo esencial en un caso de uso es especificar lo que hace el sistema que es relevante para el negocio o para ese actor en particular. Por ejemplo, para un actor es significativo que el sistema busque y muestre los datos de una factura o le indique que no la encontró, pero no es importante si esa búsqueda ocurre mediante un método secuencial, uno binario, la técnica de Fibonacci o un algoritmo genético, o si usa el mismo método de google para encontrar páginas en Internet.

También puede ocurrir que estamos especificando una funcionalidad del sistema que es posible documentar mejor con otros mecanismos como diagramas de actividad o estado o, si es necesario documentación textual, con requisitos escritos a la usanza tradicional de: “el sistema debe hacer algo…”. También se pueden usar escenarios, tableros de historias (storyboards), prototipos o simuladores, o una combinación de dos o más de estos artilugios.

Ejemplo

El siguiente caso de uso para reservar sillas en un viaje por avión nos ilustra muy bien esta sugerencia:

Caso de Uso: Reservar tiquetes

Actor: Cliente (Aerolínea)

Secuencia Básica:

1.    El caso de uso inicia cuando el Cliente decide reservar tiquetes aéreos

2.    El sistema solicita seleccionar la ciudad origen

3.    El Cliente selecciona la ciudad origen

4.    El sistema solicita seleccionar la ciudad destino

5.    El Cliente selecciona la ciudad destino

6.    El sistema solicita la fecha de ida

7.    El cliente ingresa la fecha de ida

8.    El Sistema solicita la fecha de regreso

9.    El Cliente ingresa la fecha de regreso

10.  El sistema solicita el número de pasajeros

11.  El cliente ingresa el número de pasajeros

12.  El sistema verifica que hay disponibilidad de vuelos entre las ciudades y fechas solicitadas

13.  El sistema verifica que hay disponibilidad de asientos para el número de pasajeros establecidos

14.  El sistema muestra el mensaje “Sí hay disponibilidad de vuelos  entre las ciudades y fechas establecidas”

15.  El sistema genera un número de reserva

16.  El sistema almacena la información de la reserva

17.  El caso de uso termina

Aquí caímos en la típica descomposición funcional que se debe evitar durante la etapa de requisitos. Los pasos 12 a 17 bien pueden reemplazarse por:

12. El sistema verifica que hay asientos disponibles y muestra el número de reserva.

13. El caso de uso termina

¿Y qué se hicieron las otras especificaciones? ¿Será que los programadores son capaces de inferirla? No. Estos otros detalles pueden documentarse como requisitos especiales en el caso de uso o como elementos de diseño (por ejemplo, estableciendo en un diagrama de secuencia cuáles son las entidades de almacenamiento de información o el algoritmo para generar el número de la reserva). Nótese que estos aspectos no son relevantes para el negocio.

Casos de Abuso, Parte 12: El Ingeniero de Requisitos es un psíquico

Bueno, esta me la sé también con Analistas, con Diseñadores, con Programadores y hasta con Gerentes de Proyectos. También con usuarios. Cada uno de nosotros piensa que todos los demás en el proyecto están igualmente motivados, que tienen las mismas habilidades, que conocen todo el entorno necesario para entender el sistema. Y No es así. También creemos que los demás piensan como nosotros mismos, que ven el universo como lo vemos nosotros. Y Tampoco es así.

Como receptores de información siempre tenemos un mecanismo infalible: “el qué más.” Como en ¿Qué más debo saber de este proceso? ¿Qué más me puede decir de este modelo? ¿Qué otra cosa esconde este escenario? ¿Quién más necesita esta funcionalidad? ¿En qué otro momento se requiere esta información? Como emisores también debemos estar prestos a brindar toda la información que requiera nuestro interlocutor. ¿Qué más necesita saber? ¿Tiene alguna otra pregunta? ¿Son necesarios más ejemplos? ¿Quiere hablar con alguien más?

Y no me refiero solamente a la comunicación usuario-analista, sino también a la que ocurre al interior del equipo de desarrollo: cuando presentamos los casos de uso, cuando exponemos la arquitectura, cuando mostramos la realización de casos de uso o el modelo de datos y, sobre todo, cuando documentamos el software. Todo esto debemos hacerlo con la premisa de “documentar para el resto”, para el resto de la organización, para el resto del equipo del proyecto, para los usuarios, para los socios de negocios, para los proveedores, incluso para personas ajenas al producto, al proyecto y a la misma compañía, como consultores, expertos del dominio de negocio o técnico y otro tipo de personas. Este es otro de los momentos cuando recomiendo el uso formal de UML y del español (o de algún otro idioma necesario) acorde al público, o sea, terminología del negocio para los usuarios, léxico técnico para los técnicos.

Impacto en la calidad: Medio.

Aquí termina por ahora este análisis, al menos en lo que se refiere a la enumeración de casos de abuso. Volveremos con un capítulo sobre conclusiones y recomendaciones.

Entre tanto, ¿qué otros errores se les ocurren? ¿Qué otros abusos creen que han estado cometiendo ustedes o sus colegas?

No dejen de contarme y lo discutiremos 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.