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

Presentación del tema: "Facultad de Ingeniería Proyecto de Ingeniería de Software 2010 Grupo 4 Grupo 4 1."— Transcripción de la presentación:

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

2 2

3 3

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

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

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

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

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

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

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

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

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

13 13

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

15 15

16 16

17 17

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

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

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

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

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

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

24 24 Pruebas de Sistema: 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 base de datos Verificación - Pruebas Realizadas

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

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

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

28 28 Pruebas de Configuración Metodología Se conectaron dos maquinas de configuración similares 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 Metodología Se verificó que los documentos coincidieran con lo que Se verificó que los documentos coincidieran con lo que especificaba el modelo MUM. Verificación - Pruebas Realizadas

29 29 Positivos Se cumplió con lo establecido en el plan de VyV en la mayoría de los casos. 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

30 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.

31 31 Revisiones de documentos Revisiones de documentos Revisiones semanales de los documentos a entregar cada semana Revisiones “formales” e “informales” Formal: RTF, Revisión de SQA 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.

32 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.

33 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.

34 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.

35 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.

36 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.

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

38 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 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

39 39 ConclusionesVentajas: Documentos generados de mayor calidad, lo cual repercutió en un mejor entendimiento de dichos Documentos generados de mayor calidad, lo cual repercutió en un mejor entendimiento de dichos documentos por parte del equipo documentos por parte del equipo Corrección a tiempo de errores en documentos claves 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 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 Control de los entregables semanales y el cumplimiento con la agenda y los entregables pendientes pendientes

40 40 ConclusionesDesventajas: Muchos documentos a revisar en ciertas semanas, lo cual provocó que no todos pudieran ser revisados Muchos documentos a revisar en ciertas semanas, lo cual provocó que no todos pudieran ser revisados detenidamente detenidamente Realizar verificaciones profundas resultó muy Realizar verificaciones profundas resultó muy costoso en cuanto a esfuerzo 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 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

41 41 Ambiente controlado : SVN SVN GxServer: GxServer:PúblicoPrivado Seguimiento de liberaciones Respaldos

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

43 43

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

45 45 Funcionó: 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 Reuniones semanales extras a las Quincenales para organizar las actividades de la semana Reasignar Roles según fuera necesario Reasignar Roles según fuera necesario

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

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