Facultad de Ingeniería

1. Facultad de Ingeniería Proyecto de Ingeniería de Software 2010 Grupo 4 1

2. 2

3. 3

4. Elaboración 4 semanas 6/9/10-3/10/10 Transición 2 semanas 1/11/10-14/11/10 Inicial 5 semanas 9/8/10-12/9/10 Construcción 5 semanas 4/10/10-7/11/10 4

5. Logros: • Consolidación del equipo de trabajo. • Relevamiento de requerimientos. • Definición del alcance preliminar. • Construcción del Prototipo. Fase Inicial 5

6. Logros: • Diseño completo del sistema a nivel de Contratos de software • Relevamiento completo de los requerimientos • Definición del alcance final • Desarrollo de principales funcionalidades. Fase de Elaboración 6

7. Logros: • Desarrollo de todas las funcionalidades acordadas en el alcance. • Elaboración de pruebas del sistema. • Liberación de versiones beta del producto. Fase de Construcción 7

8. Logros: • Ejecución de las pruebas del Sistema • Desarrollo de la documentación asociada al producto • Reuniones de prueba y aceptación con el Cliente • Creación de Scripts de instalación y ejecución. Fase de Transición 8

9. Fase Inicial • El tramite de las licencias GeneXustomó más de lo pensado retrasando la construcción del prototipo. Se comenzó a implementar usando la versión trial. • El cliente planteó nuevos requerimientos en la reunión de aceptación del alcance, lo cual requirió prolongar una semana la fase para especificar los nuevos requerimientos y validar el alcance. 9

10. Fase de Elaboración • Las estimaciones de tamaño y esfuerzo en base a GXPointsno resultaron ser de utilidad para nuestro producto. El juicio de expertos fue la principal herramienta utilizada para evaluar la factibilidad. • Los contratos y la implementación presentaban grandes diferencias. Se modificaron los contratos y se realizaron reuniones de equipo para lograr una visión común. 10

11. Fase de Construcción • Se dedicó gran parte de la fase a solucionar errores del producto construido en fase de elaboración, lo cual retrasó la construcción del producto final. Se decidió liberar una versión beta anticipada a fin de validar parte del producto mientras el resto era finalizado. También se prolongó una semana extra la fase 11

12. Fase de Transición • Las pruebas de performance dieron resultados no aceptables. Se dispuso a todos los implementadores a mejorar la performance y al final de la fase se lograron valores satisfactorios 12

13. 13

14. Tamaños en GXPoints • Fase Inicial: 595,2 • Fase Elaboración: 3051 • Fase Construcción: 5736 • Fase Transición: 7314 14

15. 15

16. 16

17. 17

18. Comunicación centralizada vía mail a través del Administrador Flexibilidad para renegociar requerimientos Cliente técnico Buen ambiente de trabajo. Demoras en algunas contestaciones. Escasa retroalimentación de versiones beta 18

19. Cliente: 3 personas Opiniones distintas para algunos requerimientos 2 reuniones semanales con el cliente: Disposición por parte del mismo para reuniones propuestas Sistema complejo de entender: Algunos requerimientos no especificados claramente Requerimientos puntuales de Monitorización y BPMN no especificados Agregado de los mismos a fines de la fase inicial, por lo que hubo que renegociar y priorizar requerimientos 19

20. Problema de generación de la aplicación web en Java y ambientes de desarrollo con sistemas operativos de 64 bits. Utilización de timers. Implantación de base de datos y servidor web en distintos servidores. 20

21. Herramientas utilizadas: • PivotalTracker (Reporte y Seguimiento de Bugs) • Google Group (Reporte y Seguimiento de Bugs) • HeidiSQL (Estado de la base de datos) • GXTest (Automatización de pruebas) 21

22. Pruebas Unitarias: • Importante cantidad de casos de prueba • Gran relevancia pues la aplicación es orientada a servicios • Se automatizaron algunos de estos casos de prueba utilizando GXTest • Metodología empleada: Test de caja negra Verificación - Pruebas Realizadas 22

23. Pruebas de Integración: • Lógica centralizada facilitó la tarea de verificación • Metodología empleada: Test de caja negra Verificación - Pruebas Realizadas 23

24. Pruebas de Sistema: • Prueba de integridad de los datos y la base de datos: Metodología Ejecución de casos de prueba (Datos validos e inválidos) Utilización de HeidiSQL para controlar el estado de la base de datos Verificación - Pruebas Realizadas 24

25. Pruebas de Funcionalidad: • Automatización de algunos casos • Fuerte hincapié en estas pruebas • Metodología Ejecución de Casos de Prueba Pruebas de Ciclo de Negocio: • Metodología: Elaboración de procedimiento GeneXusque simulan las actividades del proyecto en el tiempo. Verificación - Pruebas Realizadas 25

26. Pruebas de Performance • Metodología Se cargo la base de datos con diferentes volúmenes 1200,6000 y 42000 instancias Luego se midió que tiempo demoraba en completar y tomar una tarea Verificación - Pruebas Realizadas 26

27. Pruebas de Carga • Metodología Se conectaron 3 computadoras a una red inalámbrica y se probo tomar y completar workitems de forma concurrente. Pruebas de Volumen • Metodología Se utilizaron los volúmenes utilizados para las pruebas de ciclo de negocio y performance. Verificación - Pruebas Realizadas 27

28. Pruebas de Configuración • Metodología Se conectaron dos maquinas de configuración similares a las especificadas por el cliente, una como servidor de base de datos y la otra con la aplicación corriendo. Pruebas de Documentos • Metodología Se verificó que los documentos coincidieran con lo que especificaba el modelo MUM. Verificación - Pruebas Realizadas 28

29. Positivos • Se cumplió con lo establecido en el plan de VyV en la mayoría de los casos. • Se mejoró la calidad de la verificación a medida que avanzaron las etapas. Negativos • Se contó con poco tiempo para verificar. • Se automatizaron pocos casos de prueba. Verificación – Resultados 29

30. Actividades principales realizadas en el área • Revisiones de documentos • Gestión de los entregables semanales • Elaboración del plan de calidad del proyecto • Identificación de atributos de calidad del producto y verificación del cumplimiento de los mismos. 30

31. Revisiones de documentos • Revisiones semanales de los documentos a entregar cada semana • Revisiones “formales” e “informales” Formal: RTF, Revisión de SQA Informal: Revisiones semanales de documentos, revisando formato y contenido, basándose en la plantilla de cada documento. • RTF: Se realizó una vez para ciertos documentos relevantes. Insumió un tiempo considerable, por lo cual no fue realizado mas veces. Permitió detectar posibles puntos a agregar o corregir. 31

32. Revisiones de documentos • Revisión de SQA: No se realizó, en su lugar se realizó la actividad de verificación de documentos por parte del grupo de verificación, ya que se consideró que eran tareas similares. • Revisiones “informales”: Se realizaron semanalmente, antes de cada entrega. Se le dio prioridad a estas revisiones a lo largo del proyecto, ya que resultaron ser las mas útiles en cuanto a relación esfuerzo/tiempo para encontrar errores. 32

33. Revisiones de documentos • Metodología de las revisiones “informales”: El equipo de SQA realizó revisiones de documentos comparando el contenido y formato con las plantillas, se recopilaban los errores encontrados y estos eran enviados a los responsables de cada documento. Si el error era un error “menor” y en cuanto a formato, era solucionado por quien realizaba la revisión. 33

34. Revisiones de documentos • En cada etapa del proyecto se realizaron revisiones mas profundas a los documentos críticos de cada etapa, para aprovechar de una mejor forma el tiempo disponible para realizar revisiones, y asegurar la calidad de los documentos claves. A modo de ejemplo: Documento de requerimientos en fase inicial, descripción de la arquitectura en fase de elaboración, documentación de usuario en fase de construcción y transición. 34

35. Gestión de entregables semanales • El equipo de SQA se encargaba de realizar las entregas semanales, de gestionar las últimas versiones de los documentos a ser entregados y asegurar la calidad de los mismos con las revisiones semanales. También se encargaba de controlar que entregables fueron planificados y cuales efectivamente se entregaron en cada semana, así como los entregables pendientes de semanas anteriores. Esto ayudó a alivianar la carga horaria del administrador. 35

36. Plan de calidad del Proyecto • En las primeras semanas se elaboró este plan, que en el transcurso del proyecto sufriría ajustes y cambios, ya que por ejemplo se optó por no realizar revisiones de SQA “formales” y solo un RTF a ciertos documentos, debido a la carga horaria que esto hubiera insumido, y al tiempo que le hubiera quitado a otras actividades mas relevantes. 36

37. Atributos de calidad del Proyecto • Eficiencia • Portabilidad • Funcionalidad • Mantenibilidad: Documentación y Estándar de implementación 37

38. Atributos del calidad del Producto • Eficiencia: el grupo de verificación realizó pruebas de volumen para verificar que se cumplía con este requerimiento. Los resultados finales para las operaciones involucradas fueron cercanos a lo esperado • Estándar de implementación: Se realizaron comprobaciones en forma de “Muestreos” tomando aleatoriamente operaciones implementadas, para comprobar el nivel de cumplimiento del estándar. Los resultados fueron en general positivos, mostrando que se cumplió con la mayoría de los puntos indicados en el estándar 38

39. Conclusiones • Ventajas: • Documentos generados de mayor calidad, lo cual repercutió en un mejor entendimiento de dichos documentos por parte del equipo • Corrección a tiempo de errores en documentos claves • Asegurar que se cumplan con los atributos de calidad del producto y de la documentación generada • Control de los entregables semanales y el cumplimiento con la agenda y los entregables pendientes 39

40. Conclusiones • Desventajas: • Muchos documentos a revisar en ciertas semanas, lo cual provocó que no todos pudieran ser revisados detenidamente • Realizar verificaciones profundas resultó muy costoso en cuanto a esfuerzo • Demasiadas actividades de revisión que resultaron difíciles de cumplir en el tiempo estipulado, lo que obligó a elegir las prioritarias y/o las que dieron mejores resultados 40

41. Ambiente controlado: • SVN • GxServer: Público Privado Seguimiento de liberaciones Respaldos 41

42. Lo Bueno: • Excelente relacionamiento y buen ambiente de trabajo. • Amplia disposición para realizar las tareas. • Ausencia de conflictos. Lo malo: • Falta de iniciativa en etapas iniciales. • Ausencia de reuniones de integración. 42

43. 43

44. Funcionó: • Reuniones de implementación y prueba (trabajar en el mismo lugar físico) • Uso de GxServer (ahorro de trabajo de consolidado) • Uso de Google groups: Como medio de comunicación para el grupo y seguimiento de bugs. 44

45. Funcionó: • No seguir el MUM estrictamente, usándolo como una simple guía • Reuniones semanales extras a las Quincenales para organizar las actividades de la semana • Reasignar Roles según fuera necesario 45

46. No funcionó: • Estimaciones con GxPoints (defectos en herramienta para contabilizar). • Tiempo destinado para realización de pruebas del sistema resultó escaso. • Uso de Pivotaltracker: Pocos integrantes en el grupo comprendió su funcionamiento. • Estimaciones de esfuerzo por juicio de expertos 46

47. Brindar una mejor introducción al modelo de proceso, en especial indicando cual es el uso apropiado del mismo. Realizar las clases de apoyo en etapas más tempranas, algunas de ellas no se hicieron hasta ya terminada la fase inicial. 47