Descargar la presentación
La descarga está en progreso. Por favor, espere
Publicada porFelisa Toledo Gómez Modificado hace 8 años
1
Taller de Desarrollo de Proyectos II (75.47) 2º cuatrimestre 2008
2
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).
3
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
4
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
5
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
6
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
7
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.
8
Reuniones informales y formales intercaladas por lunes. Minuta de Reunión (firmada) Reporte de Avance (firmado) Comunicación en el equipo: Emails Assembla (SVN, tickets, documentos)
9
Utilizamos el método “Wideband Delphi” por horas: optimista, mas probable, pesimista
10
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.
13
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.
15
Pruebas al sistema: Ejecución de casos de prueba
16
Bugs
17
Evolución de la prueba
18
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.
19
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
20
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.
Presentaciones similares
© 2024 SlidePlayer.es Inc.
All rights reserved.