1 / 60

Management MultiSuite

Facultad de Ingeniería. Management MultiSuite. Proyecto de Ingeniería de Software 2011. Facultad de Ingeniería. Presentación del proceso. Proyecto de Ingeniería de Software 2011. Integrantes. Agenda. Fases del Proyecto Desempeño en las diversas disciplinas Funcionamiento del grupo

Download Presentation

Management MultiSuite

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Facultad de Ingeniería Management MultiSuite Proyecto de Ingeniería de Software 2011

  2. Facultad de Ingeniería Presentación del proceso Proyecto de Ingeniería de Software 2011

  3. Integrantes

  4. Agenda • Fases del Proyecto • Desempeño en las diversas disciplinas • Funcionamiento del grupo • Evaluación del proceso

  5. Fases del proyecto

  6. Fase Inicial • Duración real : 5 semanas (1-5) • Principales logros: • Consolidación del equipo • Adaptación al proceso • Riesgos • Relevamiento de requerimientos • Construcción de un prototipo • Alcance preliminar

  7. Fase Inicial • Desviaciones y medidas • Costosa adaptación al modelo de proceso • Atraso por volatilidad de requerimientos

  8. Fase de Elaboración • Duración real: 6 semanas (5-10) • Principales logros • Relevamiento de requerimientos • Diseño del sistema • Comienzo de implementación del producto • Alcance Final

  9. Fase de Elaboración • Desviaciones y medidas • Atraso 1er Liberación (Malas estimaciones) • Nuevos Requerimientos (Seguridad y otros) • Atraso cierre de fase (2da Liberación)

  10. Fase de construcción • Duración real: 5 semanas (9-13) • Principales logros • Construcción completa de la aplicación • Importantes pruebas del sistema

  11. Fase de construcción • Desviaciones y medidas • Atraso en Liberación Beta de la aplicación • Demoras en verificación • Atraso de cierre de fase

  12. Fase de Transición • Duración real: 2 semanas (13-14) • Principales logros: • Entrega de Liberación Beta y manuales al cliente • Obtención de la Liberación final de la aplicación • Informes finales del proceso

  13. Fase de Transición • Desviaciones y medidas • Problemas de instalación de la Liberación Beta • Atraso en informes finales debido a pruebas

  14. Desempeño en las diversas disciplinas

  15. Análisis de requerimientos • 1 reunión por semana 40-60 minutos • 8 personas aproximadamente • Planificación previa de la reunión • Requerimientos funcionales en su mayoría • Complejidad de requerimientos (aplicación abstracta) • Negociación de alcance

  16. Verificación • Pruebas Unitarias • Pruebas de caja negra con interfaz por defecto (debugger) • Registro en planilla en la nube • Pruebas de integración • Big Bang • Pruebas de caja negra

  17. Verificación - GxUnit • Automatización rápida de pruebas unitarias • Diseño y construcción de pruebas • Módulo Security • 1 test conteniendo procedimientos de creación y verificación de instancias • Resultados • Errores antes y después de su solución

  18. Verificación • Pruebas de Sistema • Diseño y ejecución de casos de prueba • Realización de testing exploratorio • Retroalimentación de registro de bugs • Reporte de pruebas • Registro en planilla en la nube

  19. Verificación • Resultados – Pruebas de Sistema

  20. Gestión de proyecto • Plan de iteración • Gestión de riesgos • Planilla para seguimiento • Tamaño del producto • Productividad: Aproximadamente 1 GxPoint/Hora

  21. Gestión de proyecto • Estimaciones • GxPoints en base a prototipo con malos resultados • Estimación en base a Juicio de Experto • Implementación : • Total del proyecto • Según carga horaria hasta semana 6 del proyecto

  22. Gestión de proyecto • Promedio de horas por integrante

  23. Gestión de proyecto • Totalidad de horas por área

  24. SQA • Revisiones técnico formales • Reuniones: • 3-4 personas (Responsable SQA, Asistente SQA, Implicados) • 2 horas • Documentos: • Especificación de requerimientos • Descripción de la arquitectura • Modelo de diseño

  25. SQA • Revisión semanal de SQA • Detalle de que documentos se entregan semanalmente • Calidad de documentos en base a plantillas • Seguimiento de documentos atrasados

  26. SCM • Herramientas usadas para gestión de documentos • DropBox • Jerarquía utilizada: • Herramientas usadas para el código • GxServer servidor público

  27. SCM • Gestión de cambios • Seguimiento de Línea Base: • Plan de proyecto • Especificación de requerimientos • Modelo de casos de uso • Pautas para la interfaz de usuario • Descripción de la arquitectura • Modelo de diseño • Modelo de datos • Manejo del ambiente controlado • Comité de control de configuración • Administrador • Responsable SCM • Analista • Implementador • Arquitecto

  28. SCM • Cambios menores • Sin aprobación (Mail al responsable de SCM) • Planilla de aviso • Cambios mayores • Requiere aprobación del Comité • Documento de solicitud de cambios • Se informa del cambio y este se aprueba o se rechaza

  29. Problemas técnicos • Problemas generales con Genexus • Alta capacidad computacional para el entorno • Problemas de implantación

  30. Relación con el cliente • Buena disponibilidad • Comunicación • Semanal durante análisis • Vía mail durante todo el proyecto (rápida respuesta) • Ventajas y desventajas por ser cliente técnico

  31. Funcionamiento del grupo

  32. Funcionamiento del grupo • Relacionamiento • Buena relación entre los integrantes • Conflictos menores durante el proceso

  33. Funcionamiento del grupo • Comunicación • Comunicación mayoritariamente vía mail • Grupos de Google • Analistas • Implementadores • General • Documentos informativos • Reuniones por áreas • Reuniones quincenales

  34. Evaluación del proceso

  35. Evaluación del proceso • Funcionó • Planificación • Guía de MUM • Memoria organizacional • Definición de nuevos roles • Clases de apoyo • No funcionó • Reuniones por áreas con niveles altos de asistencia y bajos niveles de productividad • Seguir el proceso demasiado en semanas con mucha carga

  36. Evaluación del proceso • Sugerencias de cambios • Clases de apoyo referentes al proceso • Clases de apoyo más tempranas • Manejar prioridad en documentos • Definir documentos opcionales en las entregas

  37. Muchas gracias

  38. Facultad de Ingeniería Presentación del producto Proyecto de Ingeniería de Software 2011

  39. Agenda • Principales Requerimientos • Alcance comprometido y logrado • Arquitectura y su relación con requerimientos explícitos e implícitos • Evaluación del producto

  40. Principales requerimientos

  41. Manejo de eventos y relaciones • Requerimiento principal del producto • Manejo de eventos y relaciones para configurar aplicaciones dinámicamente. • Tipo de eventos y tipos de relaciones. • Manejo de datos en eventos • Manejo de fórmulas en eventos

  42. Manejo de eventos y relaciones (cont.)

  43. Versionado de eventos • Configuración de eventos versionables • Se modifican los datos de un evento y se genera una nueva versión. • Posibilidad de volver a versiones anteriores.

  44. Herencia • Se puede crear un «sub tipo de evento», a partir de otro tipo de evento. Heredando así los atributos del mismo.

  45. Manejo de Usuarios y gruposPermisos • La aplicación manejará usuarios y grupos. • En los grupos es donde se define los permisos sobre ciertos eventos. • Estos permisos podrán ser específicos sobre un evento particular: • Ver • Modificar • Destruir • O permisos generales • Crear, eliminar y modificar tipos de eventos, datos y relaciones • Crear eventos

  46. Configuración de Vistas • Requerimiento importante. • Define la navegación. • Con las vistas definidas sobre un evento se podrá: • Definir la navegabilidad desde un evento, esto es, que relaciones se verán desde la vista. • Definir que menús se verán y que contendrán en la vista de cada tipo de evento. • Definir si un evento es una aplicación. • Definir que datos se verán y aplicar filtros sobre ellos.

  47. Definición de Organizaciones • Usuarios asociados a organizaciones. • «Instancia» del producto independiente de otra organización. • Súper usuario capaz de crear organizaciones y administradores de las mismas («Marcos»).

  48. Alcance comprometido y logrado

  49. Alcance • El alcance se planteó en forma de casos de uso. • Se llegó al alcance acordado.

More Related