proyecto de ingeniería de software grupo 3 (2009) tecnología.net informe de cambio de fase

Proyecto de Ingeniería de Software Grupo 3 (2009) Tecnología .NET

Informe de cambio de Fase

Agenda

Diseño del Sistema Objetivo Resultados

Gestión de riesgos Seguimiento Mitigación

Gestión del proyecto Plan de desarrollo Seguimiento

Gestión de la configuración Línea base del proyecto Gestión de cambios

Conclusiones generales

Proyecto de Ingeniería de Software 2009 - Grupo 3 - Tecnología .NET

Objetivos y resultados

Diseño del Sistema


Diseño del Sistema

Objetivos

Lograr un diseño completo del sistema

Validar diseño con el cliente

Estabilización de la arquitectura

Comunicar diseño a equipo de desarrollo

Alcance completamente definido


Diseño del Sistema

Resultados Se logró un diseño completo del sistema La arquitectura esta estabilizada y validada con

el cliente Se comunicó el diseño al equipo de

implementadores mediante una puesta en común

El alcance del sistema esta completamente definido y el diseño es coherente con el mismo

Aun no se recibió la respuesta del cliente acerca de la validación del diseñoProyecto de Ingeniería de Software 2009 - Grupo 3 -

Tecnología .NET

Diseño del Sistema

Arquitectura

1

SOAP - Web Services

1

Navegador Web

Móvil

Servidor Mobile

HTTP

Diagrama de la

arquitectura del sistema. Muestra los

distintos componente

s y los protocolos

de comunicación que se

usan.


Diseño del Sistema

Diagrama de paquetes

que muestra la descomposi

ción en subsistemas

para el producto.

Descomposición en subsistemas

Logica ServidorServidor

Base de datosDAOServidor Web

Administación

Logica Cliente

UI Cliente


Diseño del Sistema

Conclusiones

Se logró el objetivo principal, lograr un diseño completo del sistema.

La arquitectura ha sido estabilizada y se logró un diseño coherente con la misma.

Se logró comenzar con las tareas de implementación.


Seguimiento y mitigación

Gestión de riesgos


Gestión de riesgos

Listado de riesgos mas relevantes Estado actual Estrategia de mitigación

Conclusiones


Gestión de riesgos

Limitaciones de la plataforma .NET Compact Framework para el desarrollo de UI

Estado actual Tecnología inmadura Limitaciones sobre lo que podemos hacer Necesidad de realizar “workarounds”

Estrategia de mitigación Se han investigado las distintas posibilidades Se realizaron prototipos con interfaces graficas avanzadas para

evaluar la opinión del cliente Conclusión

Es un riesgo importante pero se lo tiene bajo control Buena respuesta del cliente al evaluar los prototipos


Gestión de riesgos

Poca capacidad de procesamiento en la plataforma objetivo

Estado actual Plataforma móvil ofrece recursos limitados en cuanto a memoria y

capacidad de procesamiento Pruebas en emuladores no alcanzan para asegurar un nivel

aceptable de performance Estrategia de mitigación

Se están utilizando herramientas para medir el uso de recursos del teléfono

Se cuenta con tres teléfonos para realizar pruebas concretas en la plataforma objetivo

Se realizaron prototipos que tuvieron un buen desempeño Conclusión

Es uno de los riesgos mas importantes del proyecto Se acompañara el desarrollo con mediciones de performance para

actuar con rapidez ante posibles inconvenientesProyecto de Ingeniería de Software 2009 - Grupo 3 -

Tecnología .NET

Gestión de riesgos

Ubicación del hosting para el servidor

Estado actual Necesitamos un host para levantar el servidor del juego Además necesitamos contar con un respaldo ante fallas

Estrategia de mitigación Se investigaron las distintas posibilidades y se optó por

realizar el hosting en la casa de uno de los integrantes del grupo

Se cuenta con un servidor de contingencia en la casa de otro integrante del grupo para poder responder ante caídas del servidor principal

Conclusión El riesgo se encuentra bajo control Se vio un buen desempeño del servidor en las pruebas con

prototiposProyecto de Ingeniería de Software 2009 - Grupo 3 -

Tecnología .NET

Gestión de riesgos

Dificultad de sincronización de gran cantidad de clientes

Estado actual La sincronización de varios clientes es el desafío técnico mas

importante Se necesita un buen mecanismo de manejo de concurrencia

para asegurar el buen funcionamiento del juego Estrategia de mitigación

Se realizó un prototipo para sincronizar quince clientes, numero objetivo del cliente. Fue muy útil pues se detectaron problemas que es importante resolver en el producto final

Se realizarán pruebas de carga en la semanas diez y once Conclusión

El riesgo es muy importante y por lo tanto lo estamos monitoreando con especial atención


Gestión de riesgos

Conclusiones

La elaboración de prototipos fue nuestra principal herramienta para evaluar riesgos técnicos.

Se aprendió mucho de los mismos y se logró una gran comprensión de los problemas a los que nos enfrentaremos las próximas semanas.


Planificación, seguimiento

Gestión del proyecto




Estado actual según el modelo

Presente


Plan de desarrollo

Estado actual Se elaboró el plan de desarrollo para la construcción

del producto durante la próxima fase Se abarca todo el alcance comprometido y se deja

un colchón de tiempo considerando posibles atrasos Objetivos

Apegarnos al plan lo máximo posible y respetar los plazos establecidos

Realizar una verificación continua durante el desarrollo, se deja tiempo al final del desarrollo para corrección de fallas

Cumplir con los hitos del desarrollo


Gestión de proyecto


Diagrama burn down



Conclusiones

Contamos con un plan de desarrollo elaborado.

Hemos estimado la duración del desarrollo dejando un colchón de tiempo para posibles desviaciones.

Línea base del proyecto

Gestión de la configuración



Se ha definido la línea base

Se incorporaron los distintos proyectos que forman la solución Mobile ServerLogic ServerDB AdminWebSite DataTypes

Estos elementos se incorporarán al proceso de gestión de cambios a partir de su primera versión estable. Actualmente esta versión está en fase de construcción.



Elementos que conforman la Línea Base Proyecto adminWebSite Proyecto ServerDB Proyecto ServerLogic Proyecto DataTypes Proyecto Mobile Prototipo RQDRQ RQALS RQPIU RQOOMDO



RQMOD GPISP DSARQ DSMDI DSOOMDA VRPVV VRMCP GPPIT GPPLA IMPII GPPDE GPDRI SQAPLA SCMPLA

Las modificaciones a estos elementos se hacen siguiendo el proceso de gestión de cambios.

Quien solicita una modificación debe hacerlo formalmente mediante el formulario de solicitud de cambio que se encuentra en la carpeta “general” del repositorio.

Una vez solicitado el cambio se asigna un responsable o varios para su análisis e implementación en caso de ser aprobado.

Esto permite realizar un seguimiento por parte del SCMR de los cambios



Gestión de Cambios

Las modificaciones a estos elementos se hacen siguiendo el proceso de gestión de cambios.

Quien solicita una modificación debe hacerlo formalmente mediante el formulario de solicitud de cambio que se encuentra en la carpeta “general” del repositorio.

Una vez solicitado el cambio se asigna un responsable o varios para su análisis e implementación en caso de ser aprobado.

Esto permite realizar un seguimiento por parte del SCMR de los cambios que están llevándose a cabo.


Conclusiones generales

Contamos con el diseño del sistema. Se ha elaborado el plan de desarrollo del

proyecto. Se ha definido la línea base del proyecto

y los mecanismos de gestión de cambios.

Conclusión: Creemos que estamos listos para encarar la próxima fase.


Preguntas


proyecto de ingeniería de software grupo 3 (2009) tecnología.net informe de cambio de fase

Documents