Modelo del proceso Proyecto de ingeniería de software 2010 – Grupo 3 - UdelaR

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

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

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

Fase Inicial  Llevó más tiempo del planificado: Falta de experiencia en trabajo en equipo. Atraso en la mitigación de riesgos técnicos (Mucha carga para los especialistas técnicos).  Logros: Requerimientos especificados y validados Mitigación de riesgos técnicos Definición temprana de la interfaz gráfica Arquitectura inicial elaborada y validada Acuerdo de alcance preliminar Prototipos

Fase de Elaboración  Llevó mucho más tiempo de lo esperado  El atraso fue generado por: Atrasos en el diseño (especialistas técnicos tuvieron mucha carga de diseño). Falta de cuentas de Azure (impedía validar la arquitectura)  El cierre de fase formalmente fue tardío, pero se iniciaron actividades de la siguiente fase. Logros: Arquitectura estable Diseño completo Alcance definitivo

Fase de Construcción  Excepcionalmente corta. Habíamos adelantado mucho en la fase anterior. Logros: Construcción de software y material asociado completa. Verificación de lo construido. Muchas validaciones con el cliente. Errores nuestros: Quedaron bugs menores pendientes para la fase siguiente.

Fase de Transición  Extremadamente corta en nuestro caso.  Actividades del MUM no aplicaron. En cambio hicimos: Documentación técnica, e instructivo de instalación.  Mejora de la calidad del producto final, corrección de bugs menores.  Entrega final al cliente.

Líneas de trabajo  Requerimientos  Verificación  SQA  SCM  Gestión de Proyecto

Líneas de trabajo - Requerimientos  Se tuvo que aprender a tratar con el cliente a distancia.  Varias validaciones de lo relevado.  Equipo proactivo, propuestas generadas para mejorar el juego.  Prototipos tempranos (sobre todo GUI) como otra forma de validación.

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 encuentra un error Verificador reporta error Implementador asignado soluciona cambia el estado a “Fixed” Cierre del error (Corrección correcta) Verificadores comprueban que la solución sea correcta (Corrección incorrecta)

Líneas de trabajo - SQA  Requerimientos de calidad: Estándar de codificación de Microsoft (FxCop) Estándar Marketplace de Microsoft Interfaz atractiva e intuitiva  Revisión sobre las entregas semanales  Revisiones de SQA  Revisiones Técnicas Fromales (RTF)  Se cumplió con un 95% de las actividades propuestas en el plan de SQA

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.

Línea de trabajo – Gestión de proyecto  Métricas de dedicación: Promedio de horas por persona

Línea de trabajo – Gestión de proyecto  Estimaciones y Mediciones TamañoEsfuerzo

Línea de trabajo – Gestión de proyecto  Total de horas por línea de trabajo

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

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

Experiencia con el modelo  Implicó una gran curva de aprendizaje respecto a las actividades a realizar.  Primera experiencia en un proceso formal de desarrollo.  Se siguió el proceso con algunos ajustes: Priorización a tareas de GUI Mucho tiempo dedicado a investigación Pocas actividades de transición  Propuestas: Evaluar la distribución de los roles para proyectos similares: Más especialistas y diseñadores de GUI, menos analistas. Evaluar modificaciones en fase de transición para casos de trabajo a distancia.

Producto

Agenda Que es Friend Buster Cuales eran los objetivos Requerimientos Alcance Arquitectura Evaluación

¿Que es Friend Buster? Es un juego basado en “Where in the world is Carmen San Diego?” modificado para integrar redes sociales.

¿Cuales eran los objetivos? Usamos facebook y wikipedia como fuente principal de datos para el juego. Y además utilizar todo el potencial de Bing Maps, para viajes. News, para noticias de famosos. Web, para pistas de ciudades. Images, para fotos de personajes.

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

Los requerimientos… No Funcionales 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

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

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

Evaluación Interfaz intuitiva Mecanismo de juego cómodo y atractivo Ranking de puntuaciones motiva jugar Fortalezas – windows Phone 7

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

Evaluación Debilidades 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

Evaluación Debilidades – Bugs conocidos 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

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

Demo