Taller de Desarrollo de Proyectos II (75.47) 2º cuatrimestre 2008

 Julián Lastiri  Desarrollador  Bárbara Sulpis  Tester  Leonardo Ariel Salatino  Project Manager  Alejandro Molinari  Cliente  La metodología de desarrollo RUP propone una gran cantidad y variedad de roles (Test Manager, Test Analyst, Test Designer, Tester). Muchos de los cuales, para la medida de nuestro proyecto, no tenían sentido; por lo que minimizamos los roles haciéndolos mas generales (Tester).

 Planificación: alcance, estimaciones, equipo y roles, calendarización, asignación de tareas  Plan de Desarrollo de Software.doc  Calendario Funcionalidades.doc  Calendario Tareas.doc  Entregas Incrementales.xls  Análisis: Identificación de requerimientos  Especificación de Requerimientos.doc  Análisis: Especificación funcional  Especificación de casos de uso.doc

 Configuración y versionado  Plan de Gestión de Configuración.doc  Arquitectura y Diseño Técnico  Documento de Arquitectura de Software.doc  Seguimiento y Control: Indicadores y métricas  Plan de medición.doc  Análisis de Valor Ganado.doc  Seguimiento y Control: Riesgos  Plan de manejo de Riesgos.doc  Lista de Riesgos.xls

 Comunicación  Minuta de Reunión.doc  Reporte de Avance.doc  Pruebas: Planificación y criterios de aceptación  Plan de aceptación del Producto.doc  Especificación Casos de Prueba.doc  Pruebas: Diseño y ejecución  Plan de Pruebas.doc  Pruebas: Seguimiento de Bugs  TCT – Testing.xls

 Trazabilidad  TCT – Requerimientos.xls  Plan y Estrategia de Despliegue  Plan de Despliegue.doc  Manual de Usuario.doc  Criterios de aceptación de la entrega por parte del cliente  Plan de aceptación del Producto.doc  Cierre y Lecciones aprendidas  Lecciones aprendidas.doc

 Gran cantidad de documentos, y los mismos son muy grandes. En nuestro proyectos usamos el 50 % de los templates que encontramos; y por cada uno utilizamos menos del 30 % de las secciones que poseían.  Todos los documentos se deben versionar y se debe seguir con un registro de versiones en la primera hoja desde el primer momento.

 Reuniones informales y formales intercaladas por lunes.  Minuta de Reunión (firmada)  Reporte de Avance (firmado)  Comunicación en el equipo:  s  Assembla (SVN, tickets, documentos)

 Utilizamos el método “Wideband Delphi” por horas: optimista, mas probable, pesimista

 Mala performance al inicio del proyecto (gran cantidad de horas insumidas y poca funcionalidad desarrollada); debido al aprendizaje inicial (técnico y de negocio).  Una vez superada esta curva de aprendizaje el desarrollo adquirió gran velocidad.  Conclusión: se debe planificar menos funcionalidad al inicio y tener en cuenta el costo inicial del aprendizaje.  40 % para tiempo de administración (mucha documentación).  Seguimiento a nivel de detalle de requerimientos  no computamos el tiempo de administración que nos tomó cada requerimiento  Medimos Earn Value solo para tareas de desarrollo y testing  Conclusión: El tiempo de administración se debe controlar y realizar su seguimiento como un ítem separado, fuera de los requerimientos.

 El Earn Value se debe comenzar desde el primer día de desarrollo  O controlar y realizar el seguimiento desde el día que comenzamos Earn Value  El desarrollo comenzó en etapas muy tempranas del proyecto, luego comenzamos a utilizar Earn Value y nos costó armar las horas que ya habíamos usado. (Nos basamos en mails viejos del grupo o commits hechos al repositorio de código)  Al inicio, el seguimiento por Earn Value se realizaba sin tener una separación por requerimientos  Si se presentaba un problema no sabíamos de donde venía  Comenzamos a llevar Earn Value basado en requerimientos, para así saber exactamente que requerimiento es el que produce atraso en el calendario o exceso de costos.

 Pruebas al sistema: Ejecución de casos de prueba

 Bugs

 Evolución de la prueba

 Los casos de prueba solo muestran pasos de ejecución y utilización del sistema.  Deberían existir casos de éxito, con datos válidos, y casos de error con datos inválidos  Se debería armar una tabla con los resultados esperados en cada caso  Deberían existir dos tipos de pruebas: las de persistencia (datos) y las de comportamiento (funcionalidad)  La planilla de testing, no tiene un formato suficientemente claro.  Tiene una única solapa que lista las corridas por casos de prueba indicando la fecha.  Deberíamos haber tenido una solapa por día de corrida, y en ella listar todos los casos de pruebas que se corrieron.

Plan de Aceptación  Cliente ejecuta y aprueba los casos de prueba  Funcionalidad entregada con:  0 errores críticos  1 error medio  2 errores bajos

 RUP es una metodología demasiado grande y compleja, por lo que aplicarla puede implicar cambios muy grandes de cultura del grupo. Nosotros debimos customizar y minimizar la metodología y documentos a nuestras necesidades. RUP es para proyectos de gran envergadura, no para pequeños y discutible para medianos.