Sistema de Administración de Macro Currículos (SAMA) Líder: Carlos Andrés Muñoz Desarrollo:...

Preview:

Citation preview

Sistema de Administración de Macro Currículos (SAMA)Líder: Carlos Andrés MuñozDesarrollo: José Luis GutiérrezCalidad y Proceso: Juan David BoteroSoporte: Carlos Hernán BrugnoniPlaneación: Juan Fernando DomínguezPlaneación: Juan Felipe Aranguren Checa

Grupo: Grupo 1

DESCRIPCIÓN GENERAL

3

Requerimientos

No. Descripción

1 Migrar 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écnicos

No. 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écnicos

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

Lanzamiento Estrategia Requerimientos Diseño Postmortem Seguimiento

3 34

12

7

4 4 4

1

3

10Estimado Real

14

Actividades Críticas

Planeación Inspección Diseño

Programación Inspección Código

Pruebas

4 2

50

103

6 5

63

12

4

Estimado Real

15

Rendimiento según Objetivos

Objetivo Indicador 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

Debe tender a 100% 95%

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

Carlos Muñoz Jose Luis Gutierrez

Juan F. Dominguez

Juan F. Aranguren

Juan D. Botero

Carlos Brugnoni

Líder Desarrollo Planeación 1 Planeación 2 Calidad Soporte

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

4.9 4.8 5.0 4.9

3.4 3.23 3 3 3 3 3

Calificaciones de Grupo

Consolidado Global del rol Esperado

18

Admón. de la Configuración

• Estrategia:– 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ó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: Lunes Martes Miércoles Jueves Viernes Sábado

14:00

Desarrollo

15:00

16:00

Desarrollo Desarrollo17:00

18:00Seguimiento

19:00

20:00

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

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

Reporte del Líder de Planeación

31

• 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

Reporte del Líder de Planeació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 backups debidamente 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.

BALANCE GENERAL

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

Preguntas

MUCHAS GRACIAS