Sistema de Administración de Subastas Inversas

Presentación del tema: "Sistema de Administración de Subastas Inversas"— Transcripción de la presentación:

1 Sistema de Administración de Subastas Inversas
SUBI Grupo 2 75.47 – Taller de Desarrollo de Proyectos II

2 Agenda Metodología de trabajo Lineamientos Tecnologías a utilizar
Estimación de Alto Nivel

3 Metodología de trabajo
SCRUM

4 Lineamientos Planificación Alcance: User Stories
Estimaciones: mediremos en Story Points Equipo y Roles Product Owner: Representante de SUBi ScrumMaster: Maximiliano Stibel Equipo Ezequiel Ladelfa Juan José Ramos Diego Campos Maximiliano Stibel Calendarización:  Sprints de 2 semanas Asignación de tareas: Autoorganización del equipo

5 Lineamientos Análisis
Identificación de requerimientos brainstorming Especificación funcional Wiki pages Configuración y versionado Repositorio en assembla Arquitectura y diseño técnico Arquitectura en capas UI Capa de Servicios Capa de Negocio Capa de Acceso a Datos Pruebas unitarias automatizadas Maven 2 Integración Continua Junit Testing Unitario Pruebas unitarias automatizadas: Maven 2: para automatizar las pruebas utilizaremos este framework como soporte a la integración continua. [No se si esto se puede utilizar desde el Build del assembla.] Junit: haremos testeos unitarios sobre las BEs para asegurar el correcto comportamiento del negocio. Seguimiento y Control Indicadores y métricas. Burn Down chart: uno para el Sprint y otro para todo el proyecto. Cobertura de la prueba: dados los casos de prueba planificados, al finalizar cada Sprint se mostrará este indicador actualizado como muestra de avance (por ser la prueba en paralelo con el desarrollo). Evolución de la prueba: en etapa de estabilización, para verificar la convergencia de bugs y negociar los pendientes a fin de proyecto. Cobertura de código: sobre los test unitarios podemos medir el coverage, para saber cuanto estamos testeando con los mismos. Gestión de riesgos: haremos una lista de riesgos, con la siguiente información ID: identificador único. Causa: causa del riesgo. Consecuencia: lo que sucede si el riesgo se transforma en problema. Probabilidad de ocurrencia: de 1 a 10. Impacto: de 1 a 3. Exposición: probabilidad x impacto. Mitigación: que hacer para bajar la probabilidad o el impacto. Contingencia: solo para los de mayor exposición, como reaccionar si se convierten en un problema. Antes de cada Sprint se van a analizar los riesgos existentes y se agregan nuevos o sacan los que ya no van a suceder. Luego se prioriza por exposición y se analizan acciones a seguir. Comunicación Entre el equipo: assembla (wiki, mensajes, standup, etc.). Mails. Con el cliente: reunión quincenal de revisión del sprint y planeamiento del siguiente [reunión formal]. Reunión quincenal de avance, a mitad de Sprint [reunión informal]. Pruebas Planificación y criterios de aceptación: se van a planificar casos de prueba a ser ejecutados. Los mismos van a ser acordados con el cliente. Diseño: se especificarán los casos de prueba especificando los datos de entrada, las acciones que debe realizar, tanto el usuario como el sistema y el resultado esperado. Ejecución: No se automatizarán, serán ejecutados por un integrante del equipo quién además será el responsable del indicador de cabertura de la prueba. Seguimiento de BUGs: en la etapa de construcción generarán tareas (User Stories ¿?) nuevas que deben ser incluidas en algún Sprint según la priorización del cliente. En la etapa de estabilización generará tracking de BUG y se llevará el estado de cada uno mediante el indicador de evolución de la prueba. Las tareas componen el Sprint Backlog. Cada US (en el product backlog) está relacionada con N tareas (en el Sprint backlog). Los bugs dependiendo de la herramienta pueden ser considerados como product backlog Items o Sprint Backlog items. Una forma de atacarlo es considerar un Bug como una US y asociarle tareas en un sprint dado (bugfixing, research, reproducción, etc) Trazabilidad Toda tarea debe estar asociada a una User Story, de esta manera nos aseguramos que solo estamos haciendo trabajo de lo que se definió como alcance. Los BUGs también deben estar asociadas a las mismas y daremos por completa una US cuando no tenga pendientes o cuando los mismos hayan sido negociados con el cliente. Plan y estrategia de despliegue Se va a planificar una instalación de acuerdo a la arquitectura definida. Criterios de aceptación de la entrega Se van a negociar con el cliente para cada hito o entrega dependiendo de lo que implique la entrega. Esto se definirá en la reunión de planeamiento del Sprint con el cliente. Cierre y lecciones aprendidas Resumen de los logros, descripción de lo que no se hizo y de las métricas finales. Descripción de casos interesantes de analizar que enriquezacan la formación del equipo.

6 Lineamientos Seguimiento y Control
Indicadores y métricas Burn Down chart Cobertura de la prueba Evolución de la prueba Cobertura de código Gestión de riesgos Lista de riesgos en Assembla Comunicación Entre el equipo assembla mails Con el cliente reunión quincenal de revisión del sprint y planeamiento Reunión quincenal de avance, a mitad de Sprint Seguimiento y Control Indicadores y métricas. Burn Down chart: uno para el Sprint y otro para todo el proyecto. Cobertura de la prueba: dados los casos de prueba planificados, al finalizar cada Sprint se mostrará este indicador actualizado como muestra de avance (por ser la prueba en paralelo con el desarrollo). Evolución de la prueba: en etapa de estabilización, para verificar la convergencia de bugs y negociar los pendientes a fin de proyecto. Cobertura de código: sobre los test unitarios podemos medir el coverage, para saber cuanto estamos testeando con los mismos. Gestión de riesgos: haremos una lista de riesgos, con la siguiente información ID: identificador único. Causa: causa del riesgo. Consecuencia: lo que sucede si el riesgo se transforma en problema. Probabilidad de ocurrencia: de 1 a 10. Impacto: de 1 a 3. Exposición: probabilidad x impacto. Mitigación: que hacer para bajar la probabilidad o el impacto. Contingencia: solo para los de mayor exposición, como reaccionar si se convierten en un problema. Antes de cada Sprint se van a analizar los riesgos existentes y se agregan nuevos o sacan los que ya no van a suceder. Luego se prioriza por exposición y se analizan acciones a seguir. Comunicación Entre el equipo: assembla (wiki, mensajes, standup, etc.). Mails. Con el cliente: reunión quincenal de revisión del sprint y planeamiento del siguiente [reunión formal]. Reunión quincenal de avance, a mitad de Sprint [reunión informal]. Pruebas Planificación y criterios de aceptación: se van a planificar casos de prueba a ser ejecutados. Los mismos van a ser acordados con el cliente. Diseño: se especificarán los casos de prueba especificando los datos de entrada, las acciones que debe realizar, tanto el usuario como el sistema y el resultado esperado. Ejecución: No se automatizarán, serán ejecutados por un integrante del equipo quién además será el responsable del indicador de cabertura de la prueba. Seguimiento de BUGs: en la etapa de construcción generarán tareas (User Stories ¿?) nuevas que deben ser incluidas en algún Sprint según la priorización del cliente. En la etapa de estabilización generará tracking de BUG y se llevará el estado de cada uno mediante el indicador de evolución de la prueba. Las tareas componen el Sprint Backlog. Cada US (en el product backlog) está relacionada con N tareas (en el Sprint backlog). Los bugs dependiendo de la herramienta pueden ser considerados como product backlog Items o Sprint Backlog items. Una forma de atacarlo es considerar un Bug como una US y asociarle tareas en un sprint dado (bugfixing, research, reproducción, etc) Trazabilidad Toda tarea debe estar asociada a una User Story, de esta manera nos aseguramos que solo estamos haciendo trabajo de lo que se definió como alcance. Los BUGs también deben estar asociadas a las mismas y daremos por completa una US cuando no tenga pendientes o cuando los mismos hayan sido negociados con el cliente. Plan y estrategia de despliegue Se va a planificar una instalación de acuerdo a la arquitectura definida. Criterios de aceptación de la entrega Se van a negociar con el cliente para cada hito o entrega dependiendo de lo que implique la entrega. Esto se definirá en la reunión de planeamiento del Sprint con el cliente. Cierre y lecciones aprendidas Resumen de los logros, descripción de lo que no se hizo y de las métricas finales. Descripción de casos interesantes de analizar que enriquezacan la formación del equipo.

7 Lineamientos Pruebas Planificación y criterios de aceptación Casos de Prueba Diseño Especificación de entradas y salidas esperadas. Criterios de Usabilidad Ejecución Manuales (Demos) Seguimiento de BUGs Tipificación como User Stories Trazabilidad Sprints ->User Stories Plan y estrategia de despliegue Se va a planificar una instalación de acuerdo a la arquitectura definida Criterios de aceptación de la entrega Hitos por Sprint Cierre y lecciones aprendidas Reunión de Cierre de Proyecto

8 Tecnologías a utilizar
Lenguaje de Programación Java Entorno de Desarrollo Eclipse Frameworks J2SE Maven2 Hibernate Junit Base de Datos MySQL Repositorio de Código Subversion

9 Estimación de Alto Nivel
User Story Story Points Como comprador en el sistema, quiero poder crear subastas y asignarle una cantidad y descripción de productos relacionados. 2 Como operador de subasta, quiero poder autorizar a los proveedores participantes y decidir cuáles serán preseleccionados para la subasta final. 1 Como proveedor en el sistema, quiero poder suscribirme a las distintas subastas a partir de los productos que ofrezco. Como operador de subasta, quiero poder modificarla y/o cancelarla en caso de ser necesario. Como operador de subasta, quiero poder determinar qué proveedor es el ganador y ofrece la mejor oferta. Como administrador del sistema, quiero poder inhabilitar por mora a un proveedor y que no pueda participar de ninguna subasta hasta modificar dicha situación. Como proveedor en el sistema, quiero poder participar, realizando lances en tiempo real, en subastas en las cuales poseo autorización. 3 Como operador de subasta, quiero poder iniciar, monitorear, pausar, reanudar y finalizar, en tiempo real, una subasta ya evaluada. 4

10 ¡Muchas gracias por su atención!
? ¿Dudas, consultas? ¡Muchas gracias por su atención! Grupo 2 Taller de Desarrollo de Proyectos II