Análisis y Balance del Proyecto Análisis Inicial Estimación Inicial Arquitectura de Datos Propuesta Tecnología Metodología aplicada Estimaciones elaboradas.

Presentación del tema: "Análisis y Balance del Proyecto Análisis Inicial Estimación Inicial Arquitectura de Datos Propuesta Tecnología Metodología aplicada Estimaciones elaboradas."— Transcripción de la presentación:

1

2 Análisis y Balance del Proyecto Análisis Inicial Estimación Inicial Arquitectura de Datos Propuesta Tecnología Metodología aplicada Estimaciones elaboradas Desviaciones – Acciones Correctivas Métricas Aciertos Lecciones aprendidas

3 Análisis Inicial FIUBA – Trabajo Práctico Red Social Alcance General Especificado Solo 3 estadísticas quedan por definir. Equipo definido, cuatro personas. Parte del calendario prefijado, cierre: Diciembre. Contacto directo con el Cliente (la cátedra). Disponibilidad de reuniones semanales con el Cliente. Dedicación part-time de todos los integrantes del equipo. Tecnología y licencias sin restricciones. No se requiere Mantenimiento. Especificación Funcional Casos de Uso Diagramas UML Puntos de Función Riesgos reconocidos al Inicio Es la primera vez que trabajamos juntos en equipo. No tenemos la misma experiencia en el desarrollo de este tipo de sistemas. El alcance está poco especificado Basados en que entregamos una DEMO esto es una propuesta al Cliente: En Casos de Uso: Todos los acordados con el Cliente.

4 Estimación Inicial Por Experto 350 hs desarrollo 50 hs de reuniones 100 hs de pruebas 100 hs de administración Total = 600 hs de proyecto. Despliegue en el tiempo 4 integrantes 14 semanas Total Por persona = 12hs/semana

5 Arquitectura de Datos Propuesta Presentación Aplicación Usuario Perfil Grupos Debates Reportes Búsquedas Servicios Persistencia Tablas

6 Tecnología Lenguaje Java 1.5 Frameworks Sprint Hibernet Struts 2 Ajatag – Dojo Freemaker Base de Datos Postgresql 8.4 Apache Tomcat 6 Otras tecnologías: RoR Insoshi social software http://github.com/insoshi/insoshi CommunityEngine - http://www.communityengine.org/

7 Metodología Aplicada Metodología APF Un Responsable de Proyecto Un Responsable de Negocio Un Responsable de Pruebas Un Responsable de Configuración Los Desarrolladores Los Controladores de Calidad de Producto Controlador de Calidad de Proceso (Auditor) Cliente Responsable de Usuarios Metodología Aplicada Un Responsable del Proyecto, que se olvidó de hacer minutas. Un Responsable de Negocio, ayudante. Un Responsable de pruebas, sin formalizarse. Un Responsable de configuración, sin formalizarse. Los Desarrolladores, que resultaron 2 y medio. Los Controladores de Calidad, sin formalizarse. Los controladores de Calidad del Producto, de a ratos todos. Control de Calidad del Proceso, sin formalizarse. Cliente, ayudante. Responsable de Usuarios, ayudante.

8 Estimaciones elaboradas Método Wideband Delphi Dos Iteraciones Diferencias Registrar Usuario 10,25 / 6 hs Modificar Perfil de Usuario 6,75 / 2 hs Buscar Grupo por Usuario 6,25 / 9 hs Corrección de Errores Incluida / 20hs Estimaciones Generales Total Desarrollo 279 hs Total Estimado por Experto 350 hs

9 Mayor demanda de trabajo en la segunda etapa del proyecto. Tomar tareas en función de la velocidad de desarrollo del equipo. Modificación de la documentación y planificación de la próxima iteración con prioridad en la corrección. Pruebas basadas en Unit Test y en seguimiento de ciclos de negocio Happy Pass. Tomando en cuenta el riesgo. Desviaciones – Acciones Correctivas Retraso por tomar iteraciones de poca ganancia funcional. Falta de un miembro Diferencias en la interpretación de la Recomendación de Contacto. Falta de Documentación de Pruebas.

10 Métricas Horas utilizadas en Desarrollo y Corrección de Errores.

11 Métricas Earn Value.

12 Métricas Horas utilizadas en Desarrollo y Corrección de Errores.

13 Métricas Horas utilizadas en todo el proyecto.

14 Aciertos Por medir las propuestas en base a la velocidad de desarrollo del equipo no sufrimos de forma muy significativa la pérdida de un integrante. Por conocer la tecnología, los tiempos de las indefiniciones, página de Inicio y Reportes consumieron poco tiempo. La división de los datos ordinarios de los de relaciones desde el Análisis facilitó la arquitectura y las modificaciones. Fuimos descubriendo los artefactos que no nos serían útiles y tuvimos la iniciativa de quitarlos del proyecto (WBS, JMETER, Mejora de la Documentación).

15 Lecciones aprendidas Probar el ambiente en el que se implementa. Administrar Riesgos durante todo el proyecto y utilizarlos para dialogar con el Cliente sobre la próxima iteración. A pesar de utilizar una metodología de iteraciones cortas y poca documentación, mantener una estimación general para saber cuánto nos falta. Analizar las propuestas de funcionalidad ganada para la próxima iteración en función de lo que resta del proyecto y no solo de la velocidad de desarrollo del equipo. Buscar la aceptación del Cliente en cada paso y registrar la de las entregas en forma explícita. Documentar las pruebas a cada paso del proyecto. Tomar una posición proactiva en la comunicación con el Cliente.

16 ¿Consultas?