Programacion 4

Republica Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Universitaria
Instituto Universitario de Tecnología de Ejido Ext. Tucaní
Tucani Estado Mérida







Especificaciones de Casos de Uso.





Luis Fermín Darme Ch.
C.I.No.V.= 9726969
Especificaciones de Casos de Uso:
Si entra basura, sale basura... una gran verdad en cualquier proceso, a menos tedediques al reciclaje de desechos (lo cual es poco probable dado el tema de la revista que tiene en sus manos). Los proyectos de software no son la excepción; si no iniciamos el desarrollo partiendo de requerimientos correctamente establecidos tendremos muchos problemas para lograr que al final todos los involucrados queden satisfechos.
la mayoría de los proyectos de software que fallan tienencomo causa principal una mala administración de requerimientos. Un ejemplo en este sentido suele ser un mal entendimiento de los requerimientos entre usuarios y desarrolladores.
el equipo de desarrollo cree comprender lo que el cliente le está solicitando, existe una buena probabilidad de que no sea así. Incluso me atrevo a decir que en la mayoría de las ocasiones lo que yo he visto es que en lasprimeras etapas ni siquiera el cliente está totalmente consciente de qué es lo que quiere o necesita.
Ahí es donde el analista entra al rescate, pues debe facilitarle al usuario expresar sus necesidades para validarlas posteriormente mediante mecanismos eficientes de comunicación que ambos entiendan. Un ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.

Paraespecificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos:
1. Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina.
2. Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, etc.)
3. Nivel de detalle. Los casos de uso y susespecificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.
4. Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cadauno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.
5. Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar con éste que lo documentado en las especificaciones delos casos de uso es lo que requiere para su sistema, así que si no los entiende no cumplirán su propósito principal.
Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un documento más claro que cuando lo escribendirectamente sin platicarlo. La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de forma escrita.

Flujo principal del caso de uso “Registrar Venta”
 El vendedor solicita el registro de una nueva venta.
 El sistema solicita los datos de cada uno de los productos de la venta.
 El vendedor registra la cantidad y clave de cada uno de losproductos.
 El sistema muestra la lista de productos con su cantidad, clave, descripción, subtotal, IVA y total.
 El sistema solicita el tipo de pago.
 El vendedor indica pago al contado o con tarjeta de crédito.
 Dependiendo de la selección comienza el flujo alterno “Pago al contado” o “Pago con tarjeta de crédito”.
 Una vez realizado el pago se registra la venta, se actualiza el inventario...