Historias de usuario y Casos de uso AgileM

1. Historias de usuario y Casos de usoAgileM

2. Historia de usuario (HU) HU explica como varios actores podrían interactuar con el sistema (directa o indirectamente)para lograr un objetivo. HU no es un CU HU representa los requerimientos de los usuario s. son una descripción de las necesidades funcionales que no debe ocupar muchas líneas. La idea que sea sencillo y que comunique la necesidad se cumple.

3. HU el objetivo es conseguir reflejar los requisitos que el cliente pide, estos debenestar redactados en un lenguaje entienda el, para poder desarrollar lo que nos esta pidiendo. El cliente no valorará una perfecta representación UML de unos requisitos que no son los que el pidió.

4. CUs • Los casos de uso son un mecanismo poderoso y simple para le definición de requisitos funcionales, son historias del uso de un sistema que pueden ser utilizados por distintas metodologías.

5. CUs Los CUs contestan las preguntas: • ¿Quiénes son los diferentes usuarios del sistema y qué papeles desempeñan? • ¿Qué necesita cada usuario que realice el sistema? • ¿Cuáles son los pasos que deben seguirse para que el sistema satisfaga las necesidades de cada usuario?

6. Ejemplo HU “El sistema debe facilitar las labores de facturación” CUs "Emitir cotización" "Emitir pedido" "Generar factura" "Generar reporte de impuestos" "Listar precios generales" "Actualizar precio de producto" "Listar precios por cliente" "Añadir descuento a producto para un cliente" "Listar servicios" "Listar vendedores" "Registrar vendedor" "Desactivar vendedor

7. Cu Generar factura "Generar factura" Flujo Normal: 1.- El usuario solicita ciertos productos. 2.- El sistema muestra la lista de productos solicitados, el precio unitario y el total de la compra. 3.- El usuario acepta la lista de productos y el precio. 4.- El sistema le pide información de pago. 5.- El usuario introduce su información de pago. 6.- El sistemas valida la información de pago y esta es correcta. 7.- El sistema imprime la factura y pide confirmación al usuario de que se imprimió correctamente. 8.- El usuario confirma la correcta impresión. 9.- El sistema cierra la operación y espera la siguiente lista de productos. Flujos Alternativos: A.- ** El sistema no puede validar la información de pago ** A.7.- El sistema muestra un mensaje de error diciendole al usuario que no pudo validar la información de pago. A.8.- Se pasa al paso 3 (solicitud de información de pago) del escenario principal) B. - ** Otra alternativa o escenario **

8. Metodología AgileM • Análisis: Historias de usuario, salidas), planificación • Diseño- Diagramas: Clases, E-R • Construcción- iteración • Pruebas • Implantación Usuario

9. Plantilla HUs Objetivo del proyecto:

10. db4o Base de Objetos de Código Abierto • Nativa a Java y .NET • 100% orientada a objetos, sin mapeo objeto-relacional • Diseñada para uso embebido • De código abierto y libre bajo la GPL • La Ventaja que Necesita en sus Tiempos de Desarrollo. • db4o reduce el tiempo y costo de desarrollo, provee un desempeño superior, y no requiere de un DBA.