1 / 33

Friend-Buster

Modelo del proceso. Friend-Buster. Proyecto de ingeniería de software 2010 – Grupo 3 - UdelaR. Agenda. Introducción Evolución en el tiempo Fase inicial Fase de Elaboración Fase de Construcción Fase de Transición Líneas de trabajo Requerimientos Implementación Verificación SQA

imogene-carson
Download Presentation

Friend-Buster

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modelo del proceso Friend-Buster Proyecto de ingeniería de software 2010 – Grupo 3 - UdelaR

  2. Agenda • Introducción • Evolución en el tiempo • Fase inicial • Fase de Elaboración • Fase de Construcción • Fase de Transición • Líneas de trabajo • Requerimientos • Implementación • Verificación • SQA • SCM • Gestión de proyecto • Relación con el cliente • Experiencia con el modelo

  3. Introducción • Grupo de 14 integrantes • Producto: Friend Buster • Cliente: Marcelo Guerra Hahn • Directores: Cecilia Apa / Javier Barreiro

  4. Evolución en el tiempo Propuesta del MUM: Inicial (4 semanas) Elaboración (4 semanas) Construcción (4 semanas) Transición (2 semanas) Realidad de nuestro proyecto: Inicial (5 semanas) Elaboración (6 semanas) Cons-trucción (2 semanas) Transición (1 semana)

  5. FaseInicial • Llevómástiempo del planificado: • Falta de experiencia en trabajo en equipo. • Atraso en la mitigación de riesgostécnicos (Muchacargapara los especialistastécnicos). • Logros: • Requerimientos especificados y validados • Mitigación de riesgostécnicos • Definicióntemprana de la interfazgráfica • Arquitecturainicialelaborada y validada • Acuerdo de alcancepreliminar Prototipos

  6. Fase de Elaboración • Llevó mucho mástiempo de lo esperado • El atrasofuegeneradopor: • Atrasos en el diseño (especialistastécnicostuvieronmuchacarga de diseño). • Falta de cuentas de Azure (impedíavalidar la arquitectura) • El cierre de faseformalmentefuetardío, pero se iniciaronactividades de la siguientefase. Logros: • Arquitecturaestable • Diseñocompleto • Alcancedefinitivo

  7. Fase de Construcción • Excepcionalmentecorta. • Habíamosadelantado mucho en la fase anterior. Logros: • Construcción de software y material asociadocompleta. • Verificación de lo construido. • Muchasvalidaciones con el cliente. Erroresnuestros: • Quedaron bugs menorespendientespara la fasesiguiente.

  8. Fase de Transición • Extremadamentecorta en nuestrocaso. • Actividades del MUM no aplicaron. • En cambiohicimos: Documentacióntécnica, e instructivo de instalación. • Mejora de la calidad del producto final, corrección de bugs menores. • Entrega final al cliente.

  9. Líneas de trabajo • Requerimientos • Verificación • SQA • SCM • Gestión de Proyecto

  10. Líneas de trabajo - Requerimientos • Se tuvoqueaprender a tratar con el cliente a distancia. • Varias validaciones de lo relevado. • Equipoproactivo, propuestasgeneradasparamejorar el juego. • Prototipostempranos (sobretodo GUI) comootra forma de validación.

  11. Líneas de trabajo - Verificación • Se resolvieron 122 de 124 Issues reportados. • Generación y actualización de datos de prueba • Usamos el Issue Tracker de codeplex. • Forma de trabajo: Verificador reporta error Verificador encuentra un error Implementador asignado soluciona cambia el estado a “Fixed” (Corrección incorrecta) Cierre del error Verificadores comprueban que la solución sea correcta (Corrección correcta)

  12. Líneas de trabajo - SQA • Requerimientos de calidad: • Estándar de codificación de Microsoft (FxCop) • Estándar Marketplace de Microsoft • Interfazatractiva e intuitiva • Revisión sobre las entregas semanales • Revisiones de SQA • RevisionesTécnicasFormales (RTF) • Se cumplió con un 95% de lasactividadespropuestas en el plan de SQA

  13. Línea de trabajo - SCM • Se definieron elementos a entrar en linea base en los fines de las fases 2 y 3. • Se manejó un método ágil de control de cambios • Se hicieron varias liberaciones a verificación, pero se mantuvo una única línea de desarrollo.

  14. Línea de trabajo – Gestión de proyecto • Métricas de dedicación: Promedio de horaspor persona

  15. Línea de trabajo – Gestión de proyecto • Estimaciones y Mediciones Tamaño Esfuerzo

  16. Línea de trabajo – Gestión de proyecto • Total de horasporlínea de trabajo

  17. Línea de trabajo – gestión de proyecto • Gestión de riesgos: • 11 Riesgos identificados: • 5 ocurrieron con variado impacto • 6 fueron mitigados correctamente • 1 Riesgo no identificado que ocurrió: • Problemas con la infraestructura

  18. Relación con el cliente • Se superó el problema de la distancia (tuvo menos repercusión de lo esperado) • Buena relación de ambas partes • Flexibilidad

  19. Experiencia con el modelo • Implicóunagrancurva de aprendizajerespecto a lasactividades a realizar. • Primeraexperiencia en un proceso formal de desarrollo. • Se siguió el proceso con algunosajustes: • Priorización a tareas de GUI • Mucho tiempodedicado a investigación • Pocasactividades de transición • Propuestas: • Evaluar la distribución de los roles paraproyectossimilares: Másespecialistas y diseñadores de GUI, menosanalistas. • Evaluar modificaciones en fase de transición para casos de trabajo a distancia.

  20. Producto Friend-buster

  21. Agenda • Quees Friend Buster • Cualeseran los objetivos • Requerimientos • Alcance • Arquitectura • Evaluación

  22. ¿Quees Friend Buster? • Es un juegobasado en “Where in the world is Carmen San Diego?” modificadoparaintegrarredessociales.

  23. ¿Cualeseran los objetivos? Usamosfacebook y wikipediacomofuente principal de datospara el juego. Y ademásutilizartodo el potencial de Bing • Maps, paraviajes. • News, paranoticias de famosos. • Web, parapistas de ciudades. • Images, parafotos de personajes.

  24. Los requerimientos… Buscar pistas… Iniciar partida …y del próximo destino del sospechoso Funcionales Viajar a un nuevo destino Arrestar al sospechoso Emitir una orden de arresto

  25. Los requerimientos… Windows Phone 7 Azure Bing Facebook Silverlight para WP7 Tiempos de respuesta aceptables (menor a 3 segs. con buen ancho de banda) Seguir la línea metro Interfaz grafica atractiva e intuitiva No Funcionales

  26. Alcance • Cliente para Windows Phone 7 • Todos los requerimientos entraron en el alcance, y además … • Desafíos • Salvar y cargar partida • Servidor de datos • Varios jugadores concurrentes • Base de datos en SQL Azure • Modulo de Administración • Pagina ASP.net con interfaz para carga de datos

  27. Arquitectura SQL Azure Azure http Administrador WCF WCF FB server FB Bing Com Web Service Web Service WP 7

  28. Evaluación • Interfaz intuitiva • Mecanismo de juego cómodo y atractivo • Ranking de puntuaciones motiva jugar Fortalezas – windowsPhone 7

  29. Evaluación • Alto grado de parametrización • Autonomía de la actualización de los datos • Requiere poco mantenimiento Fortalezas – Azure

  30. Evaluación • Pobre funcionamiento con mala calidad de conexión • Dependencia de la información en Facebook del jugador y sus contactos • Dependencia de los resultados de los motores de búsqueda Debilidades

  31. Evaluación • Mal manejo de la pérdida de conexión • No soportamos el caso de usuarios con menos de 3 amigos en facebook • No manejamos correctamente el vencimiento de tokens del login • Al cargar una jugada guardada no es posible viajar a la ciudad de retorno Debilidades – Bugs conocidos

  32. Evaluación • Integración de redes similares a Facebook • Adaptación para fuente de datos diversificada • Multilenguaje y adaptación cultural de templates Mejoras

  33. Demo

More Related