Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porJosefa Gómez Caballero Modificado hace 8 años
1
Modelo del proceso Proyecto de ingeniería de software 2010 – Grupo 3 - UdelaR
2
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
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 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:
5
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
6
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
7
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.
8
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.
9
Líneas de trabajo Requerimientos Verificación SQA SCM Gestión de Proyecto
10
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.
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 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)
12
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
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 horas por persona
15
Línea de trabajo – Gestión de proyecto Estimaciones y Mediciones TamañoEsfuerzo
16
Línea de trabajo – Gestión de proyecto Total de horas por lí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ó 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.
20
Producto
21
Agenda Que es Friend Buster Cuales eran los objetivos Requerimientos Alcance Arquitectura Evaluación
22
¿Que es Friend Buster? Es un juego basado en “Where in the world is Carmen San Diego?” modificado para integrar redes sociales.
23
¿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.
24
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
25
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
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 FB Bing Com FB server Web Service Azure WP 7 http Administrador WCF
28
Evaluación Interfaz intuitiva Mecanismo de juego cómodo y atractivo Ranking de puntuaciones motiva jugar Fortalezas – windows Phone 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 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
31
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
32
Evaluación Mejoras Integración de redes similares a Facebook Adaptación para fuente de datos diversificada Multilenguaje y adaptación cultural de templates
33
Demo
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.