1 / 43

Sistema de Administración de Macro Currículos (SAMA)

Grupo: Grupo 1. Sistema de Administración de Macro Currículos (SAMA). Líder: Carlos Andrés Muñoz Desarrollo: José Luis Gutiérrez Calidad y Proceso: Juan David Botero Soporte: Carlos Hernán Brugnoni Planeación: Juan Fernando Domínguez Planeación : Juan Felipe Aranguren Checa.

yanni
Download Presentation

Sistema de Administración de Macro Currículos (SAMA)

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. Grupo: Grupo 1 Sistema de Administración de Macro Currículos (SAMA) Líder: Carlos Andrés Muñoz Desarrollo: José Luis Gutiérrez Calidad y Proceso: Juan David Botero Soporte: Carlos Hernán Brugnoni Planeación: Juan Fernando Domínguez Planeación: Juan Felipe Aranguren Checa

  2. Descripción General

  3. Requerimientos

  4. Casos de Uso

  5. Requerimientos Técnicos

  6. Requerimientos Técnicos

  7. Diagramas Estáticos Diagrama de Conceptos

  8. Diagramas Estáticos Diagrama de Componentes

  9. Diagramas Dinámicos Diagrama de Secuencia

  10. Diagramas Dinámicos Diagrama de Secuencia

  11. Proceso de desarrollo

  12. Análisis de Riesgos Falta de comprensión de la arquitectura requerida. Problemas de configuración del framework. Problemas de reutilización de la arquitectura base. Retraso de Desarrollo. Retraso de Despliegue. Trabajo Inefectivo.

  13. Actividades

  14. Actividades Críticas

  15. Rendimiento según Objetivos

  16. Rendimiento del Equipo • Factores a evaluar: • Ayuda y soporte. • Contribución global. • Desempeño de rol. • Nivel de compromiso. • Contribución al producto.

  17. Rendimiento del Equipo

  18. Admón. de la Configuración • Estrategia: • Implementar un repositorio único en la plataforma Google Code. • Versión propia (WorkingCopy) de cada desarrollador. • Los tags sobre versiones se realizaran únicamente después de fases de prueba satisfactorias.

  19. Admón. de la Configuración • Realidad: • El trabajo con versiones propias fue efectivo más no se realizó un repositorio único.

  20. Admón. de la Configuración • Versionamiento: • Numerado, tanto para el código fuente como para los artefactos de documentación, de la siguiente manera: <versión><promoción><revisión> • <versión>: modificaciones sustanciales. • <promoción>: disposición de todos los miembros del equipo de desarrollo. • <revisión>: pequeños cambios de forma y fondo entre promociones.

  21. Organización del Equipo • En cuanto a la reunión semanal: • Las reuniones semanales servirán como mecanismo de seguimiento del desarrollo por parte de los pares y del líder del equipo. De igual manera en las reuniones se asignarán las tareas y metas por semana.

  22. Organización del Equipo Horarios:

  23. Reporte de roles

  24. Reporte del Líder • Motivación: • Bastante buena, al menos por la mayoría del grupo, todos trabajamos con una meta clara y única, la de lograr cumplir los requerimientos en el plazo establecido. • Compromisos: • Estructuración de tiempos pobre, se aplazaron algunas actividades para el final del ciclo lo que saturó definitivamente los tiempos del grupo.  • Soporte del instructor: • Se requiere mayor participación en la resolución de problemas técnicos,

  25. Reporte del Líder • Reuniones: • Las reuniones iniciales se realizaron a través de Skype, de manera virtual. • Las reuniones de desarrollo se realizaron de manera presencial para aportar todos al desarrollo de la aplicación y opinar sobre la documentación que se debía adelantar.  • Se propició la autonomía y la participación proactiva de los miembros del equipo.

  26. Reporte del Líder • Sugerencias: • Se necesita un mayor control sobre responsabilidades asignadas y trabajo de los miembros del equipo.

  27. Reporte del Líder de Desarrollo • Requerimientos: • No se logró implementar todos los requerimientos del ciclo principalmente debido a problemas con el entorno de desarrollo y el manejo de la interfaz gráfica.

  28. Reporte del Líder de Desarrollo • Estrategia de desarrollo: • La estrategia de desarrollo se basó en el trabajo sobre un solo computador. Se establecieron similitudes con la arquitectura base de la aplicación Songstock. • Se requiere configurar mas equipos para el segundo ciclo con el fin de trabajar de manera simultánea.

  29. Reporte del Líder de Desarrollo • Diseño: • El diseño (arquitectura, interfaz, base de datos) fue otorgado por el cliente, lo que limitó las decisiones de diseño. • Se prescindió del uso de Maven para garantizar la compatibilidad por problemas de versionamiento.

  30. Reporte del Líder de Planeación • Desempeño: • El seguimiento del plan fue deficiente principalmente debido a los problemas de configuración del entorno. • Hubo compromiso para realizar la documentación y programación según los requerimientos.

  31. Reporte del Líder de Planeación • Uso de la Herramienta: • Bastante complicado a pesar de tener experiencia con eclipse, la incorporación de los nuevos elementos como Glassfish, GWT, GXT y las asociaciones y dependencias entre proyectos complicaron el desarrollo de la programación

  32. Reporte del Líder de Planeación • Sugerencias: • Ser mas realista y cuidadoso a la hora de estimar los tiempos, no se tuvo en cuenta que la curva de aprendizaje fuese tan prolongada. • Los planes de mitigación deben seguirse de mejor manera para poder lidiar con los desfases de tiempo en el desarrollo.

  33. Reporte del Líder de Calidad • Estimados: • Las clases, sus atributos y métodos, de los requerimientos implementados, están adecuadamente documentados como se había planeado. • La interfaz gráfica ofrece las funcionalidades necesarias según los requerimientos del cliente.

  34. Reporte del Líder de Calidad • Disciplina del Grupo: • Se realizó control de calidad por pares al desarrollo tal y como se estipuló en la estrategia.

  35. Reporte del Líder de Calidad • Estándares de calidad: • Los estándares de calidad utilizados son adecuados, no obstante se deben precisar estándares mas específicos en cuanto a las tareas asignadas.

  36. Reporte del Líder de Calidad • Sugerencias: • Realizar un control de calidad mas exhaustivo de los documentos entregables en las primeras etapas, con el fin de garantizar que la información obtenida en los mismos sea consistente y acorde a los requerimientos.

  37. Reporte del Líder de Soporte • Logística: • Como logística pusimos como puntos de reunión la universidad y cuando se nos hacia tarde nos trasladábamos para la casa de algún compañero hasta terminar los objetivos acordados para las . • Algunos problemas surgieron en cuanto a los horarios de algunas reuniones, pero fueron cosas menores.

  38. Reporte del Líder de Soporte • Versionamiento: • Durante la primera etapa de desarrollo hubo algunos problemas con el versionamiento en cuanto al orden y algunas confusiones sobre la versión en la que se estaba trabajando. Con el paso del tiempo se solucionaron los problemas por medio de backupsdebidamente versionados.

  39. Reporte del Líder de Soporte • Sugerencias: • El rol podría ser mejor desempeñado si se le da una guía especial al alumno, ya que si esta persona tiene una pequeña ventaja sobre la tecnología y el ambiente de desarrollo, podría ejecutar su rol de una manera mas viable.

  40. Balance general

  41. Factores a Mejorar • Estimación de tiempos • Aprendizaje • Actividades • Administración del Equipo • Asignación de tareas • Criterios de calificación • Administración de la Configuración • Repositorio

  42. Preguntas

  43. Muchas gracias

More Related