1. No category

 2009 DIFICULTADES DE LOS
CASOS DE USO Susan LillySRA International, Inc.4300
Lagos Feria Ct.Fairfax, VA 22033
[email protected]
703-227-5103 Los 10 Problemas de proyectos reales utilizando Casos de Uso Resumen
Una de las bellezas de los casos de uso es su formato accesible e informal. Los casos
de uso son fáciles de escribir, y la notación gráfica es trivial. Debido a su simplicidad,
los casos de uso no son intimidantes, incluso para los equipos que tienen poca
experiencia con la especificación de requisitos formales y de gestión. Sin embargo, la
simplicidad puede ser engañosa; escribir bien casos de uso requiere habilidad y
práctica. Muchos grupos escribiendo casos de uso por primera vez, ejecutan tipos
similares de problemas. El autor presenta este trabajo de la lista de "Top Ten" de
dificultades y problemas de casos de uso, basado en observaciones de una serie de
proyectos reales. El documento describe los síntomas de los problemas, y recomienda
curas pragmáticas para cada uno. Se proporcionan ejemplos para ilustrar los
problemas y sus soluciones.
DIFICULTADES DE LOS CASOS DE USO
2009 Introducción
En los últimos años, hemos visto una serie de proyectos en sus primeros intentos de
desarrollo de casos de uso. Estos proyectos han utilizado los casos de uso en un número
de formas: como todo la especificación de requisitos del sistema, como parte de los
requisitos del sistema, como una técnica de análisis para obtener los requisitos de usuario
que se especifica posteriormente en otras formas (por ejemplo, tradicional
"Shalls"), y como requisitos de software de nivel de subsistema. Los equipos de proyecto
que desarrollan casos de uso han incluido los desarrolladores y / o analistas, en algunos
casos los equipos de proyecto han incluido clientes o usuarios finales también.
Aunque los equipos de proyecto no tuvieron problemas para empezar con los casos de
uso, muchos de ellos encontraron problemas similares en su aplicación a mayor escala.
Estos problemas incluyen sistema de límites definidos o incompatibles, modelos
complejos de casos de uso, la especificación de casos de casos uso, la longitud y la
granularidad, y casos de uso que son difíciles de entender o estar incompletos. Estos han
agrupado y resumido aquí como lista de "Top Ten" de dificultades de casos de uso y los
problemas que pueden ser encontrados por los profesionales sin experiencia.
Un simple problema es utilizado para proporcionar ejemplos sencillos a lo largo de este
trabajo. El sistema de orden de ticket es un sistema informático que se va a implementar
para simplificar las ventas a clientes para juegos de béisbol. Los clientes pueden ver el
calendario de las entradas de la temporada y la reserva en los quioscos colocados en
lugares convenientes, tales como centros comerciales. Alternativamente, los clientes
pueden llamar a un 0-800 y un secretario de teléfono les reserva entradas para ellos. El
cliente puede pagar con tarjeta de crédito, o puede pagar en el tiempo en el que las
entradas se recogen en el estadio el día del juego.
Lista de los Top Ten
Problema # 1: El límite del sistema no está definido o es inconsistente.
Síntoma: El casos uso se describen en el ámbito de aplicación del sistema incompatible algunos casos de uso en el ámbito de negocios, otros en el sistema o incluso en el
alcance del subsistema.
Uno de los elementos del modelo de casos de uso es un cuadro con la etiqueta que indica
los límites del sistema, los actores salen de este cuadro, y los casos de uso van en el
interior. Antes de determinar los actores y los casos de uso, debemos ser explícitos
acerca de lo que entendemos por "sistema". ¿Se trata de un sistema informático? ¿Una
solicitud? ¿Un componente o subsistema? ¿O es una empresa entera? Los casos de uso
se pueden utilizar para describir cualquiera de las fronteras de estos "sistemas", pero sólo
deben centrarse en uno a la vez.
Los actores y casos de uso adecuados en un límite del sistema es probable que sean
incorrectos para un límite de sistemas diferentes. Un problema común es la mezcla de
ambos ámbitos en el mismo modelo de caso uso, o incluso dentro de una especificación
de casos de uso único.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 2 DIFICULTADES DE LOS CASOS DE USO
2009 Ejemplo: Un cliente de quiosco utiliza el sistema de computadora para ordenar boletos o
ticket. Alternativamente, el usuario de teléfono puede llamar a la empresa de boletería, y
un secretario de teléfono (un empleado de la empresa de boletos) puede utilizar el
sistema informático para finalizar los boletos. ¿Quiénes son los actores? La Figura 1
ilustra una alta mezcla de límites del sistema: Los modeladores han tratado de mostrar
tanto a los usuarios de la empresa y los usuarios del sistema en el mismo modelo de
casos de uso.
Figura 1: Casos de Uso con alta mezcla de ámbitos de aplicación
Cura: Ser explícito sobre el ámbito de aplicación y la etiqueta de los límites del sistema en
consecuencia. Decir: "Sí, el modelo de negocio es muy interesante, pero ahora estamos
definiendo los casos de uso en el ámbito de aplicación del sistema informático "- y luego
se adhieren a ella Ejemplo: En la figura 2, el límite del sistema representa un sistema
informático, y el cliente del quiosco y el Secretario de teléfono son los actores del caso de
uso que utilizan la orden de ticket.
Figura 2: Casos de Uso en el Ámbito de aplicación del sistema informático
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 3 DIFICULTADES DE LOS CASOS DE USO
2009 En la Figura 3 la frontera del sistema representa una empresa entera. El actor, es decir el
cliente de teléfono, es un usuario de la empresa de boletos, pero no es un usuario del
sistema informático. Estas dos son las formas de modelo adecuadas, la elección entre
ellas depende de si estamos tratando de definir los requisitos de un sistema informático
(uso de la figura 2), o el uso de casos de uso en modelado de procesos de negocio o
reingeniería (uso de la figura 3).
Figura 2: Casos de Uso en el ámbito de negocio de empresa
Síntoma: Mirando el modelo de casos de uso, no es muy claro lo que hay dentro y lo que
fuera del sistema. Este problema a menudo aparece cuando los casos de uso se modelan
mediante una modelado visual / herramienta CASE (incluido el líder en el mercado) que
no muestra el límite del sistema en el modelo de casos de uso.
Cura: Dibujar los límites del sistema (al menos en la cabeza). Si la herramienta de
modelado no dibuja un límite de sistema, coloque los casos de uso en el interior y los
actores fuera de una caja imaginaria.
Ejemplo: Figura 4 muestra el modelo mismo de un caso uso, en formato de diferentes
maneras. El modelo de la izquierda ha confundido a los actores y los casos de uso, el de
la derecha ha colocado a los casos de uso en el medio ("dentro") con los actores en el
"exterior."
Figura 3: Modelo de Casos de Uso de formato (malo y mejor)
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 4 DIFICULTADES DE LOS CASOS DE USO
2009 Problema # 2: Los casos de uso están escritos desde el punto de vista del sistema (no de
los actores).
Síntoma: Los nombres de los casos de uso describen lo que el sistema hace, más que el
objetivo que el actor quiere lograr.
Cura: Nombre los casos de uso desde la perspectiva de los objetivos del actor.
Ejemplo: Proceso de orden de venta de entradas y muestreo de Lista son las cosas que
hace el sistema (malos nombres de casos de uso). Orden de venta de entradas y
visualizar la lista son los objetivos de los usuarios del sistema (buenos nombres de casos
de uso).
Síntoma: Los pasos en la especificación de casos de uso describen la funcionalidad
interna, en lugar de interaccionar a través de la frontera del sistema.
Cura: Concéntrese en lo que el sistema tiene que hacer para satisfacer el objetivo del
actor, no como se logrará.
Síntoma: El modelo de casos de uso se parece a una base de datos / diagrama de flujo
del proceso.
Cura: Tenga cuidado cuando el modelo de caso de uso incluye casos de uso que no
están directamente asociados con un actor, pero se asocian con <<uses>> o
<<extends>> relaciones. A veces esto es un medio adecuado para modelar los casos de
uso. Sin embargo, muchos neófitos modeladores de casos de uso (en especial los que
son programadores, o que tienen un fondo de modelado de procesos) hacen mal uso de
estas asociaciones, funcionalmente descomponen el problema, en lugar de centrarse en
las interacciones entre los actores y el sistema. Eche un vistazo a las especificaciones de
los casos utilizados o ampliación del uso, para garantizar que las medidas en ellos
describe las interacciones entre el actor (del caso de uso base) y el sistema. Si las
medidas son totalmente centradas en el proceso interno, el utilizado y extendido. Los
casos de usos pueden ser utilizados como un mecanismo para la descomposición
funcional. (Si es así, no pertenecen al modelo de casos de uso.)
Problema # 3: Los nombres de actores son incompatibles.
Síntoma: nombres de actores diferentes se utilizan para describir el mismo papel. Esto es
increíblemente fácil de hacer, ya que las diferentes fuentes de requisitos a menudo usan
nombres de las variantes de lo mismo – y nombres parecidos para cosas muy diferentes.
Cuando un problema es grande, a menudo hay diferentes equipos de trabajo en los
modelos de casos de uso para las diferentes partes del problema, y lo mismo (lógico)
el actor puede aparecer con nombres de las variantes de modelo a modelo. Ejemplo: El
papel de la persona que administra el programa de béisbol en línea se llama "Lista de
administrador" en un modelo, " Gerente del calendario" en otro, y "Programador" en un
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 5 DIFICULTADES DE LOS CASOS DE USO
2009 tercero.
Cura: Obtener un pronto acuerdo en el proyecto sobre el uso de nombres de actores (y
otros términos).
Establecer un glosario al principio del proyecto y utilizarlo para definir los actores.
El glosario debe especificar el nombre del actor, su significado, y los alias con que este
nombre es conocido.
Incluya el glosario como anexo al documento de casos de uso.
Problema # 4: Demasiados casos de uso.
Síntoma: El modelo de caso de uso tiene un gran número de casos de uso.
Remedio: Asegúrese de que la granularidad de los casos de uso es apropiado. Los casos
de uso deben reflejar "Los resultados de valor" para los usuarios del sistema - la
consecución de los objetivos de usuario real.
- Combine los casos de uso que describan el comportamiento trivial o incidental que son
en realidad fragmentos de los casos de uso reales. Los casos de uso a veces se cortan
en fragmentos cuando hay un intento de asociar las pantallas de interfaz de usuario para
los casos de uso en una relación uno-a-uno.
- Retire los casos de uso que describen puramente "internos" al sistema de proceso
("internos" con respecto a cualquier sistema de límites que se está utilizando).
Ejemplo: En la figura 5, El feliz cliente del quiosco o actor se asocia con un caso de uso
llamado orden de ticket – El objetivo real del cliente es caminar hasta el quiosco en el
centro comercial. El triste cliente del quiosco o actor se asocia con tres diferentes casos
de uso. Todos ellos describen las interacciones entre el cliente de quiosco y el sistema,
que representan el paso incidental en el logro de la meta real del actor (a fin del orden de
ticket). ¿Cómo surgió el caso de uso "real" y como obtener dividido en tres sub-objetivos
de casos de uso? Los modeladores estaban tratando de hacer un caso de uso separado
para cada elemento de la interfaz de usuario.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 6 DIFICULTADES DE LOS CASOS DE USO
2009 Figura 4: Casos de Uso Real vs Acciones accidentales
Si la granularidad de los casos de uso es correcta, pero el sistema es simplemente muy
grande, particionar el conjunto de casos de uso.
Romper el modelo de casos de uso en paquetes de casos de uso, cada uno de los cuales
contiene un conjunto coherente de casos de uso y un conjunto limitado de actores.
Ejemplo: La Figura 6 muestra un modelo caso de uso que tiene un gran número de casos
de uso.
La Figura 7 ilustra el mismo conjunto de casos de uso, dividido en 5 paquetes. Cada
paquete debe contener una "cohesión" o subconjunto de los casos de uso, agrupados en
torno a uno o más actores que comparten objetivos comunes.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 7 DIFICULTADES DE LOS CASOS DE USO
2009 Problema # 5: Las relaciones actor-caso de uso se asemejan a una telaraña.
Síntomas: (a) Hay demasiadas relaciones entre actores y casos de uso. (B) Un actor
interactúa con cada caso de uso. (C) Un caso de uso interactúa con todos los actores.
Remedio: Los actores pueden ser definidos de manera demasiado amplia. Examinar los
actores para determinar si hay funciones del actor más explícitas, cada uno de ellos
participaría en un conjunto más limitado de los casos de uso.
Ejemplo: los empleados son muy generales, y se asocian con un gran número de casos
de uso.
El Secretario Telefónico y el Administrador del Programa son más específicos, cada uno
de estos se asocian con unos más pequeños, juegan un papel más orientado a los casos
de uso.
Puede haber casos en que el reconocimiento de una clase más general de los actores
contribuye a simplificar un modelo. Esto a menudo se produce cuando dos o más actores
están asociados con el mismo conjunto de casos de uso, debido a una cierta
normalización de sus funciones. El modelo de casos de uso resultante tiene una telaraña
de líneas cruzadas entre actores y casos de uso, como se muestra en la Figura 8.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 8 DIFICULTADES DE LOS CASOS DE USO
2009 Figura 7: Actores con funciones superpuestas
El caso de uso modelando la notación proporciona un mecanismo, la generalización del
actor, de forma explícita reconoce el carácter común de las funciones del actor. La figura
9 muestra cómo el modelo de caso de uso se puede volver a dibujar con la generalización
del actor para simplificar las relaciones entre actores y casos de uso.
Este modelo dice que un cliente del quiosco es un tipo de Ticketer (cliente de factura
simple) y que un secretario de teléfono es una especie de Ticketer. Cualquier Ticketer
puede ver un calendario de ticket o el orden. Un secretario de teléfono (pero no un Cliente
de quiosco), además, puede ver un informe de ventas.
Figura 8: Modelo de Casos de Uso con la Generalización del actor
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 9 DIFICULTADES DE LOS CASOS DE USO
2009 Tenga en cuenta que no habría sido correcto, simplemente el modelo de secretario de
teléfono como una especialización de cliente de quiosco, en lugar de Ticketer. Mientras
que las relaciones del actor del caso de uso sería correcta, la relación actor-actor es
semánticamente errónea: Un vendedor de teléfono no es un tipo de cliente de quiosco. (Vi
ese ejemplo en un libro de casos de uso reciente, que modeló un representante de
ventas, donde el actor es como una subclase de un actor al cliente, con el fin de heredar
el caso de uso que se superpone a las relaciones.)
Problema # 6: Las especificaciones de casos de uso son demasiado largas.
Síntoma: La especificación de casos de uso se prolonga por las páginas.
Remedio: La granularidad del caso de uso puede ser demasiado ordinario o grosero.
Ejemplo: Programar el caso uso (un caso uso que incluye todo lo que cualquier usuario
podría desea hacer con un programa) es demasiado amplio. Para más información en
sentido estricto, los casos de uso específicos (como el Programa Ver y Crear Lista)
tienden a ser más cortos y más fáciles de entender.
Alternativamente, la granularidad de los pasos en el caso de uso puede ser demasiado
fino. Los pasos pueden ser demasiado detallados o son puramente de procesamiento
interno (aplicación). Volver a escribir que se centra en la interacción esencial.
Problema # 7: Las especificaciones de casos de uso son confusas.
Síntoma: El caso de uso carece de contexto, no significa "contar una historia."
Cura: Incluir un campo en el contexto de la plantilla de especificación de casos de uso
para describir el conjunto de circunstancias en las que el caso de uso es relevante.
Asegúrese de que el campo de contexto pone el punto de vista de cada uso caso, con
respecto a la "visión global" (el ámbito más externo siguiente). No sólo se tiene que utilizar
para resumir el caso de uso.
Síntoma: Los pasos en el aspecto de flujo normal, como un programa de ordenador.
Cura: Vuelva a escribir los pasos para centrarse en un conjunto de interacciones
esenciales entre un actor y el sistema, dando lugar a la realización del objetivo del actor.
- Romper el comportamiento condicional ("si ...") en forma separada se describen los
flujos de suplentes, dejando el flujo normal más corto y más fácil de entender.
- Los pasos del caso de uso no son particularmente eficaces para describir algoritmos no
triviales, con muchas bifurcaciones y bucles.
Utilizar otras técnicas más eficaces para describir algoritmos complejos (por ejemplo, la
tabla de decisión, árboles de decisión, o pseudocódigo).
- Asegúrese de que las medidas no especifican la aplicación. Enfoque en el exterior
interacciones.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 10 DIFICULTADES DE LOS CASOS DE USO
2009 Considere la posibilidad de expresar algunos de los comportamientos como "reglas", en
lugar de algoritmos.
Problema # 8: El caso de uso no describe correctamente el derecho funcional.
Síntomas: Las asociaciones entre actores y casos de uso no describen correctamente o
completamente quién puede hacer qué con el sistema. Este problema parece ocurrir por
dos razones:
- Los modeladores de casos de uso están tratando de ser "orientado a objetos,"
haciendo inflados u obesos a los casos uso de los que incluyen todas las acciones
posibles que podrían llevarse a cabo en un objeto comercial. (Yo llamo a estos "CRUD
casos de uso", ya que suelen contener flujos para crear, leer, actualizar y eliminar el
objeto.) Estos casos de uso a menudo tienen nombres que incluyen las palabras
"Mantener", "administrar", o "procesar".
- Los modeladores de casos de uso están tratando de hacer coincidir casos de uso a la
pantalla de interfaz de usuario. Ante una pantalla de vista, que también podría ser editado
(por un usuario con la autoridad a la derecha), que combinando la visualización y la
actualización en un caso de uso individual que se refiere a la misma pantalla de diseño.
Ejemplo: La figura 10 muestra un caso de uso de Proceso de Lista de juego, que
describe todo lo que cualquier actor desea hacer con un calendario de juegos. Su
especificación tiene un "flujo normal" de ver el calendario, y los flujos alternativos para la
actualización de la programación. El cliente del quiosco actor puede utilizar el flujo normal,
pero no puede utilizar el flujo alterno. Sólo el administrador del Programa de derecho
funcional puede realizar la actualización del programa.
Figura 9: El derecho funcional Confunde
Remedio: Asegúrese de que cada actor asociado a un caso de uso es totalmente
facultado para realizarlo. Si un actor es sólo de derecho funcional a una parte del caso de
uso, el caso de uso debe ser dividido.
Ejemplo: El Cronograma de juego del Proceso de casos de uso debe ser dividido en dos:
Vista del Horario de juego y Calendario de actualización del juego, como se muestra en la
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 11 DIFICULTADES DE LOS CASOS DE USO
2009 Figura 11. Ahora está claro, a simple vista, que el cliente del quiosco puede ver, pero no
actualizar, un horario.
Figura 10: Casos de Uso con el correcto derecho funcional
Problema # 9: El cliente no comprende los casos de uso.
Síntoma: El cliente no sabe nada en absoluto acerca de casos de uso, pero se le ha dado
documentos basados en casos de uso que requieren revisión o aprobación. (Por supuesto
que es mejor cuando clientes / usuarios finales se han incluido en el desarrollo de casos
de uso. Sin embargo, la persona que revisa y aprueba los requisitos no han participado en
el desarrollo de la utilización los casos.)
Cura: Enséñeles lo suficiente para entender.
- Colocar una explicación corta (1-2 páginas) de los casos de uso en el documento de
casos de uso, como un prólogo o apéndice. La explicación debe incluir una clave para leer
el modelo y las especificaciones, y un ejemplo sencillo.
- Dirigir una sesión de entrenamiento corto cuando el documento de casos de uso se
distribuye para su revisión.
- Pensar largo y tendido sobre el uso de <<uses>> y las relaciones <<extends>> en el
modelo de casos de uso. Se trata de una conveniencia de modelado, pero no en todos es
intuitiva a la revisión sin experiencia.
Síntomas: Los casos de uso no cuentan una historia.
Cura: Agregar información para contar la historia:
- Incluir una sección de contexto en la plantilla de casos de uso.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 12 DIFICULTADES DE LOS CASOS DE USO
2009 - Añadir una sección de información general que proporcione el contexto a un conjunto
de casos de uso relacionados (por ejemplo, un paquete), y utilizar esta sección para
"contar la historia."
Incluir otros - tipos de modelos según sea necesario. A menudo, un solo caso de uso se
traducirá en un estado de cambio a un objeto de dominio principal, pero el modelo de
casos de uso por sí solo no cuentan la historia de cómo se producen los cambios de
estado del objeto a través de muchos casos de uso con el tiempo. Un modelo de estado
(transición del estado del diagrama) de un objeto de dominio principal puede ser una
excelente manera de mostrar cómo varios casos de uso relacionados encajan con el
tiempo.
Síntoma: La organización de casos de uso no coincide con la forma en que el cliente
piensa del problema.
Cura: Determinar cuál es la estrategia para la organización de los casos de uso que tiene
más sentido al cliente. Escuche cómo el cliente describe el negocio.
- ¿Cómo particionar los casos de uso en paquetes: Romper los casos de uso por los
roles principales y actores, o por eventos importantes en el negocio del cliente.
Ejemplo: El cliente habla mucho de "organización de Primavera" - cuando se ponen
nuevos calendarios de juegos, definiciones de sección de estadio, y precios de los boletos
en el sistema. Incluso si esa no es la forma en que los desarrolladores de sistemas
piensan el sistema, que es la organización de paquetes que tienen sentido para el cliente.
- ¿Cómo comprar casos de uso dentro de un paquete: Ordenar de los casos de uso "por
orden cronológico," para describir una historia del uso del sistema a través del tiempo. No
para los casos de uso Alfabéticos!
Síntoma: El caso de uso está escrito en "ordenadores".
Cura: ¡Cuidado con la jerga informática que no forma parte del vocabulario del cliente.
Ejemplo: Decir "El sistema muestra la pantalla de resultados," en lugar de "La pantalla
invoca los resultados."
Síntoma: El cliente sólo odia a los casos de uso.
Cura: Entregar lo que el cliente quiere. Esto no quiere decir que los casos de uso no
pueden ser utilizados como una técnica de los requisitos de obtención, si los casos de uso
son realmente la técnica correcta para el trabajo. Sin embargo, no puede ser el principal
producto entregado del trabajo.
Ejemplo: Un cliente tiene su propia plantilla de documento de requisitos, y no es del caso
de uso base. Pero el sistema es de carácter muy operativo, y creemos que los casos de
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 13 DIFICULTADES DE LOS CASOS DE USO
2009 uso son el mejor enfoque para obtener y modelar los requisitos. Realizamos el caso de
uso basado en el análisis, y luego escribimos los requisitos en el formato que el cliente
quiere, sobre la base de lo que hemos aprendido en este análisis.
Los casos de uso podrían incluirse en un apéndice del documento de requisitos, o puede
que no se entregue en absoluto.
Problema # 10. Los casos de uso nunca se terminan.
Síntomas: Los casos de uso tienen que cambiar cada vez que cambia la interfaz de
usuario.
Cura: Junte libremente los detalles de la interfaz de usuario y las interacciones de casos
de uso. La interfaz de usuario en el diseño es probable que cambien, y no desean que los
requisitos del sistema dependan de diseño. (La dependencia va en sentido contrario - el
diseño de la interfaz de usuario debe satisfacer los requisitos del caso de uso). Un poco
de acoplamiento es correcto - "baja fidelidad" de imágenes de la interfaz de usuario que
pueden ayudar a la comprensión del caso de uso. Pero no demasiado compensación de
las interacciones fundamentales de los mecanismos de la interfaz de usuario (que es más
probable que el cambio). En los flujos, se centran lo esencial de lo que el actor (por
ejemplo, "selecciona un juego", "envía una solicitud") hace en lugar de cómo la interacción
es hecha (por ejemplo, "haga doble clic en el botón Enviar").
Especificar que los casos uso "disparan" eventos como condiciones previas (por ejemplo,
"el usuario ha seleccionado un juego, y le solicita que ordene boletos"), en vez de los
detalles de navegación en pantalla. Mantenga la pantalla de información de la navegación
en un documento de diseño (por separado) de interfaz de usuario, no en el modelo de
casos de uso.
Síntoma: Los casos de uso requieren cambiar cada vez que cambia el diseño.
Remedio: La respuesta fácil es "No ponga el diseño en los casos de uso." Eso es en
general un buen consejo, cuando los casos de uso se encuentran en un ámbito de
aplicación del sistema informático. Los casos de uso deben registrar lo que el sistema
debe hacer, no el diseño y los detalles de implementación. Asegúrese de que sus pasos
de casos de uso están. No innecesariamente bajo nivel, es decir, se debe especificar por
completo lo que el sistema debe hacer, pero no más que eso. Ponga la información de
diseño descubierta durante el análisis en un apartado del Diseño de Documento de
orientación.
Cuando los casos de uso se definen en un ámbito de aplicación del subsistema, los
cambios en el diseño a nivel de sistema (por ejemplo, cómo funcionalidad se reparte entre
los subsistemas) pueden afectar a los requisitos del subsistema. Hasta que el diseño del
sistema es estable (y explícitamente documentado), los requisitos del subsistema,
incluyendo los casos de uso, no se estabilizarán.
Síntoma: Hay muchos casos de alternativa posibles!
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 14 DIFICULTADES DE LOS CASOS DE USO
2009 Cura: Cuidado con "parálisis de análisis". Hay un punto en el que los requisitos son
adecuadamente especificados, y su posterior análisis y especificación no agregan calidad.
Cubra el "80%" de los casos, haga algo mejor que el resto dentro del presupuesto
asignado de tiempo y dinero.
Síntoma: Los requisitos son desconocidos.
Remedio: Los casos de uso tienen un formato sencillo, informal y accesible. Esto puede
llevar a la conclusión engañosa que el desarrollo de casos de uso es fácil. Sin embargo, la
simplicidad del formato no significa que el proceso de análisis de requerimientos es
menos crítico o más fácil. Utilizar casos de uso en un mecanismo para definir y
documentar las necesidades operativas, no magia.
Conclusiones
Los peligros y los problemas descritos en este documento no es un auto de
procesamiento de casos de uso, pero más bien los problemas en la aplicación de casos
de uso por los médicos sin experiencia. En nuestra experiencia, la mayoría utilizan
equipos de desarrollo de casos de uso de los miembros sin experiencia. Los casos de uso
pueden ser una nueva técnica para la organización, y están siendo utilizados por el
equipo de desarrollo por primera vez. Incluso cuando los analistas o desarrolladores de
sistemas con experiencia en casos de uso, otros miembros del equipo no pueden. El
equipo ideal de casos de uso incluye a los clientes, usuarios finales, y / o dominio
expertos. Los expertos. En la mayoría de los casos, estos miembros del equipo no tienen
experiencia previa en los casos de uso. La simplicidad de la notación de modelado de
casos de uso y las especificaciones de lenguaje natural hacen casos uso muy accesible a
los miembros del equipo. Ellos pueden participar plenamente en el caso de uso modelado
y especificado, pero es probable que encuentre las dificultades descritas en este
documento.
Una sugerencia para los equipos en los que algunos o todos los miembros son nuevos en
los casos de uso es realizar exámenes periódicos informales "en curso" de los modelos
de casos de uso y especificaciones, en fin de detectar problemas tempranos en el
desarrollo, y para educar a los miembros del equipo. Por supuesto, una revisión formal o
inspección de un documento de casos de uso final es también apropiado. El cuestionario
de evaluación puede ser más eficaz mediante el uso de una lista de comprobación para
ayudar a identificar estos problemas comunes.
Un ejemplo de una lista de verificación está disponible por correo electrónico a petición
del autor.
Susan LillySRA International | Los 10 Problemas de proyectos reales utilizando Casos de Uso 15