Casos+de+prueba+de+aceptacion


 * **El modelo de la ficha**
 * **Caso de Prueba de Aceptación** ||
 * **Código:** || **Historia de Usuario (Nro. y Nombre):** ||
 * **Nombre:** ||
 * **Descripción:** ||
 * **Condiciones de Ejecución:** ||
 * **Entrada / Pasos de ejecución:** ||
 * **Resultado Esperado:** ||
 * **Evaluación de la Prueba:** ||


 * **Ejemplos**

Por el momento no encontre ejemplos concretos, habria que basarse en el sigueinte concepto:

por parte de los clientes (eso creo!!!) de que el software desarrollado es acorde con sus pretensiones. Las pruebas de aceptación son un subconjunto de las pruebas manuales y las llevará a cabo personal escogido por el grupo. Se le proporcionarán a dicho personal los juegos de datos precisos.
 * Pruebas de aceptación**. Las pruebas de aceptación se basan en la comprobación

PD: no queda claro esto. averiguen

**REVISEN ESTO**

Fases del ciclo de vida de XP
Idealmente en un proyecto XP se debería abordar una fase inicial donde se realiza un desarrollo rápido, seguida de un largo periodo en el que el proyecto se encuentre en producción durante el que se completa, refina y mantiene, a través de diversas **releases**. Finalmente, desaparece cuando ya no tenga razón de ser o sea sustituido por otro proyecto. A continuación se muestran las fases que atraviesa un proyecto XP a lo largo de su historia. A continuación de describen cada una de estas fases.

Exploración
=== Planificación === Hay dos conceptos fundamentales en XP: === Iteraciones para alcanzar la primera release === === ===
 * || **Objetivo** || Disponer lo antes posible de un sistema que funcione como lo haría en producción. ||
 * **Duración** || Entre una o dos semanas. Este tiempo puede variar dependiendo de la experiencia del equipo de desarrollo, si el equipo es inexperto este periodo se podría ampliar hasta algunos meses, sin embargo, si tiene experiencia con proyectos parecidos y conoce la tecnología, el tiempo se puede acortar hasta una semana. ||
 * **Actividades** || **Los programadores**: * Prueban cada componente tecnológico susceptible de ser usado en el sistema en producción.Se realiza una exploración muy activa de las posibilidades para la arquitectura del sistema, para poder hacer comparativas y elegir la mejor alternativa.
 * Experimentan para obtener los valores límites de rendimiento de la tecnología escogida.
 * Estiman cada tarea acometida durante esta fase y tras su finalización obtienen las desviaciones con respecto a lo estimado.
 * El cliente:**
 * Debe comenzar a escribir historias durante esta fase. Inicialmente, el cliente puede no tener claro el tipo de información que debe llevar cada historia. La idea es que el jefe de proyecto dé al cliente su opinión acerca de las primeras historias que realice y le transmita lo que es necesario y lo que es accesorio para hacer la estimación del esfuerzo. ||
 * **Salidas** || * Una aproximación bastante completa (a ser posible conceptualizada con alguna metáfora)de lo que será la arquitectura final del sistema.
 * Un conjunto inicial de historias de usuario preparadas para ser discutidas y estimadas y planificadas ||
 * **Release**, se define como una versión operativa de un sistema, es decir, que puede ser utilizada por usuarios externos al equipo de desarrollo. Las ìreleasesî deben ser pequeñas, lo ideal es poner un sistema simple en producción lo mas antes posible e ir haciendo nuevas releases en ciclos muy cortos (preferiblemente de uno a tres meses).
 * **Iteración**, cada release se realiza mediante una o varias iteraciones. Se define iteración como el periodo en el que se acometen algunas de las funcionalidades propuestas para la release que el cliente considere más prioritarias. Lógicamente las iteraciones deben durar como máximo el mismo tiempo que la release (suponiendo que sólo se realiza una iteración). Sin embargo es muy aconsejable que se realicen varias iteraciones de menos tiempo cada una (preferiblemente de una a tres semanas).
 * || **Objetivo** || Realizar la planificación y seguimiento de las tareas a realizar a lo largo de cada release. ||
 * **Duración** || Está presente a lo largo de todo el ciclo de vida del proyecto. ||
 * **Actividades** || * **Planificación de la release:** determinar el ámbito de la siguiente release combinando prioridades del cliente con estimaciones técnicas. Si posteriormente la realidad se desajusta al plan, se actualiza el plan. Consta de tres fases:
 * 1) //Fase de Exploración,// el cliente y los programadores obtienen una apreciación global de lo que el sistema debería hacer.
 * 2) //Fase de Compromiso,// se decide qué subconjunto del conjunto de requisitos se va ha acometer planificando cada uno de ellos.
 * 3) //Fase de Seguimiento//, la planificación se ajusta al ritmo real de desarrollo del proyecto a lo largo de cada una de las iteraciones.
 * **Planificación de la iteración:** determinar el conjunto de tareas a realizar en esa iteración. El equipo de desarrollo aplica unas reglas similares que en la planificación de la release:
 * 1) //Fase de Exploración,// se identifican las tareas que requiere cada funcionalidad planificada para la iteración
 * 2) //Fase de Compromiso,// cada programador se responsabiliza de un conjunto de tareas y estima el tiempo que invertirá en su realización.
 * 3) //Fase de Seguimiento,// a medida que se implementa cada tarea, se hace un seguimiento del progreso del equipo y se replanifica si es necesario. Finalmente, se prueba la funcionalidad completada en la iteración. ||
 * **Salidas** || * Planificación de actividades y entregas para la release
 * Planificación de tareas de cada iteración ||
 * || **Objetivo** || Tener disponible, al final de cada iteración, el sistema para pasar a producción. ||
 * **Duración** || XP recomienda que la **release** se divida entre **una y cuatro iteraciones**. La duración aproximada de cada **iteración** no debe sobrepasar las **tres o cuatro semanas**. ||
 * **Actividades** || **Los programadores** acometen las actividades necesarias a realizar en cada tarea. Normalmente estas actividades se corresponden con: * Preparación (automatización) de las pruebas unitarias
 * Codificación
 * Integración del software modificado con el producto final
 * Realizar documentación, automatización de pruebas de aceptación, etc. cuando la tarea lo requiera.
 * Refactorización, apoyo otros miembros del equipo de desarrollo, reuniones, etc.
 * El cliente**:
 * Genera los casos de prueba para las pruebas de aceptación que verificarán la funcionalidad (historias de usuario) planificada en la primera iteración ||
 * **Salidas** || * Software integrado, probado y aceptado por el cliente en cada iteración ||