1 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
2 Descripción General
3 Requerimientos No. Descripción 1Migrar la arquitectura original de SAMA a la arquitectura de referencia. 2 Migrar y completar la interfaz gráfica de usuario original a la utilizada en SAMI 3 Administrar las excepciones
4 Casos de Uso
5 Requerimientos TécnicosNo. Nombre Descripción 1 Modificabilidad La aplicación debe construirse de tal forma que tenga bajo acoplamiento y alta cohesión para permitir cambios futuros. 2 Escalabilidad El sistema debe soportar un número creciente de usuarios sin afectar el rendimiento. 3 Usabilidad La aplicación debe permitir un aprendizaje rápido por parte de los usuarios
6 Requerimientos TécnicosNo. Nombre Descripción 1 Plataforma JEE La aplicación será desarrollada utilizando componentes del framework Java Enterprise Edition. 2 Interfaz Web en GXT La interfaz gráfica debe ser desarrollada con las herramientas de GWT-EXT (GXT).
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 ObjetivosIndicador Métrica Resultado Objetivo 1: Desarrollar un producto de buena calidad de acuerdo a las especificaciones del cliente. 1.2 Porcentaje de requerimientos incluidos en el producto final. Debe tender a 100% 50% Objetivo 2: Realizar una gerencia de proyectos productiva. 2.1 Porcentaje de error en la estimación del tiempo necesario de desarrollo. Debe ser < 25%. 30% Objetivo 3: Finalizar la implementación de la aplicación a tiempo. 3.1 Numero de días de desfase entre la finalización del desarrollo y la entrega. Debe ser < 5 7 Objetivo 4: Documentar el proyecto de acuerdo a las especificaciones del cliente. 4.1 Porcentaje de documentación realizada 95%
16 Rendimiento del EquipoFactores 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ónEstrategia: Implementar un repositorio único en la plataforma Google Code. Versión propia (Working Copy) de cada desarrollador. Los tags sobre versiones se realizaran únicamente después de fases de prueba satisfactorias.
19 Admón. de la ConfiguraciónRealidad: El trabajo con versiones propias fue efectivo más no se realizó un repositorio único.
20 Admón. de la ConfiguraciónVersionamiento: Numerado, tanto para el código fuente como para los artefactos de documentación, de la siguiente manera:
21 Organización del EquipoEn 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 EquipoHorarios: Lunes Martes Miércoles Jueves Viernes Sábado 14:00 Desarrollo 15:00 16:00 17:00 18:00 Seguimiento 19:00 20:00
23 Reporte de roles
24 Reporte del Líder Motivación: Compromisos: Soporte del instructor: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 DesarrolloRequerimientos: 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 DesarrolloEstrategia 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 DesarrolloDiseñ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ónDesempeñ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ónUso 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ónSugerencias: 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 CalidadEstimados: 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 CalidadDisciplina 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 CalidadEstá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 CalidadSugerencias: 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 SoporteLogí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 SoporteVersionamiento: 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 backups debidamente versionados.
39 Reporte del Líder de SoporteSugerencias: 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 Administración del EquipoAprendizaje Actividades Administración del Equipo Asignación de tareas Criterios de calificación Administración de la Configuración Repositorio
42 Preguntas 11/19/10 42
43 Muchas gracias