MI CUADRO COMPARATIVORealice un cuadro comparativo donde diferencie los casos de uso de las historias del usuario.CASOS DE USOHISTORIAS DE USUARIO

Objetivo, modelar la interaccin entre un actor y el sistema.Objetivo, redactar una descripcin breve de una funcionalidad tal y como la percibe el usuario.

Estructura, texto detallado donde se sigue una plantilla predefinida a completar con conceptos tcnicos (objetivo, resumen, actor, evento, disparador extensiones, etc.).

Estructura, corta y consistente en una o dos frases escritas en el lenguaje del usuario.

No se utilizan para planificar.Se utilizan para planificar.

Agilidad, se requiere tiempo para anlisis y la redaccin de plantillas predefinidas.

Agilidad, se pueden escribir en pocos minutos.

Suelen ser difcil comprensin, incluso para personal capacitado tcnico.

Fciles de leer y comprender.

Mantenimiento, suelen pertenecer a documentos con cientos de pginas difciles de mantener.

De fcil mantenimiento.

Comunicacin, modelo textual asociado con diagramas, todo tiene que ser escrito.Comunicacin, basada en la comunicacin verbal y orientada a la colaboracin y discusin para clarificar detalles.

Soporte, escritos en documentos con el objetivo de que estos sean archivados como documentos de referencia.

Soporte, escritas en tarjetas (tericas o reales) con el objetivo de que sean usadas directamente.

Duracin, puede ser implementada en varias iteraciones.

Duracin, debe ser implementada y probada en una nica iteracin.

Autores, definidos por interpretes (analistas, consultores, etc.).

Autores, posibilidad de ser definidas por usuarios y clientes.

La definicin de pruebas se redacta en documentacin separada. Contienen pruebas de aceptacin en el reverso de la tarjeta.

Contexto, proporciona una visin ms general del sistema y la integracin separada.Contexto, proporciona una visin menos obvia, por eso las pruebas y el feedback de los usuarios son tan importante en las metodologas agiles.

Metodologa, asociado con RUP.Metodologa, asociado con programacin extrema (aunque pueden usarse en RUP).

Sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/o otros sistemas.

La historia en s misma no es lo suficientemente explcita como para considerarse un contrato, la discusin con los usuarios debe permitir esclarecer su alcance y ste debe dejarse explcito bajo la forma de pruebas de validacin.

Tiene un nivel apropiado del detalle.

Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difcil o costoso

Es bastante sencillo como que un desarrollador lo elabore en un nico lanzamiento.Al ser muy corta, sta representa requisitos del modelo de negocio que pueden implementarse rpidamente (das o semanas)

Secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema.

Es ideal para proyectos con requisitos voltiles o no muy claros.

Describe una tarea del negocio que sirva a una meta de negocio.

Sin pruebas de validacin pueden quedar abiertas a distintas interpretaciones haciendo difcil utilizarlas como base para un contrato.

INGENIERIA DE SOFTWAREPgina 1