BPM-NODUM
Grupo 8 – PIS 2009 PROCESO
• Grupo• Fases• Gestión del Proyecto• Verificación• SQA• SCM• Evaluación del proceso seguido• Conclusiones
AGENDA
Presentación del Grupo
• Grupo: 15 integrantes
• Proceso: MUM
• Producto: BPM-NODUM
• Cliente: NODUM
• Director: Jorge Triñanes
Presentación del Grupo
Administrador – Asistente de Verificación - Responsable de Comunicación
Diego Bastiani Analista – Documentación de usuario – Asistente de
Verificación Javier de Prado
Analista – Implementador Ignacio Vignolo Alberto Martinucci (Representante de Analistas) Agustín Mullin
Responsable SQA – Asistente de Verificación Maximiliano Mañay
Analista – Diseñador de Interfaz de Usuario – Implementador María Emilia Silveira
Presentación del Grupo
Responsable de Verificación – Asistente SQA Lissette Colina
Arquitecto – Asistente de Verificación – Coordinador de Desarrollo
Roberto Pertusa Especialista Técnico – Implementador
Federico Orihuela Gabriela Rodriguez Virginia Rodriguez (Respresentante de Especialistas Técnicos) Lorena Calvo (Responsable de Integración)
Responsable de SCM – Especialista Técnico - Implementador Raúl Rivarola
Analista – Especialista Técnico – Implementador Marcos Suiffet
Duración de: Fases recomendadas en MUM:
Duración de: Fases experimentadas por el grupo:
FASES
Relevamiento de Requerimientos Dificultades por carencia de documentación
Problemas de organización y adaptación a roles Analisis y determinación de teconlogías a utilizar Configuración de repositorio Definición de entorno de desarrollo y plan para el mismo Capacitación autogestionada Estimación primaria basada en:
memoria organizacional puntos de función
Definición de alcance primiario
Fase Inicial
Fase de Elaboración
Relevamiento y especificación de Requerimientos Se corrige la estimación de esfuerzo y tamaño del
producto Definición de CU Definición de la Arquitectura, Modelo de Datos y Modelo
de Diseño Implementación del Prototipo
Grupos de 1 analista y 1 especialista técnico Integración de componentes:
Persistencia Servicios Nodum JgraphX
Definición de Alcance final Verificación - Planificación
Fase de Construcción
Implementación Diseñador Navegador Servidor
Verificación Funcional, a partir de CU Conflictos de configuración en ambiente de testing
Manual Usuario Desviación de 5 días Presentación de Producto Beta
Retroalimentación conjunta con cliente
Correccion de errores e implementacion de sugerencias
Versión Final del Producto
Fase de Transición
Gestión del Proyecto
Definición de mecanismos de comunicación
Planificación de proyecto
Seguimiento de la situación del proyecto
Registrar actividades del grupo
Organizar y distribuir recursos y actividades
Gestionar riesgos
Realizar estimaciones de esfuerzo y tamaño del producto
Decisiones claves tomadas por responsables de áreas
Gestión del Proyecto
Tamaño del producto en las distintas Iteraciones
Gestión del Proyecto
Tamaño del producto en las distintas Iteraciones
Gestión del Proyecto
Tamaño del producto en las distintas Iteraciones
Gestión del Proyecto
Tamaño del producto en las distintas Iteraciones
Gestión del Proyecto
SEM 1 SEM 2 SEM 3 SEM 4 SEM 5 SEM 6 SEM 7 SEM 8 SEM 9 SEM 10 SEM 11 SEM 12 SEM 13 SEM 14
0
50
100
150
200
250
300
350
400
Horas totales por semana
Horas
SEM 1 SEM 2 SEM 3 SEM 4 SEM 5 SEM 6 SEM 7 SEM 8 SEM 9 SEM 10 SEM 11 SEM 12 SEM 13 SEM 14
227 281,5 226,5 283 292,5 285 262 295 288 295 300 315 333 336
Promedio de horas por semana por:
• Grupo
0
5
10
15
20
25SEM 1
SEM 2
SEM 3
SEM 4
SEM 5
SEM 6
SEM 7
SEM 8
SEM 9
SEM 10
SEM 11
SEM 12
SEM 13
SEM 14
SEM 1 SEM 2 SEM 3 SEM 4 SEM 5 SEM 6 SEM 7 SEM 8 SEM 9 SEM 10 SEM 11 SEM 12 SEM 13 SEM 14
15,13 18,76 15,1 18,86 19,5 19 17,46 19,66 19,2 19,66 20 21 22,2 22,4
Promedio de horas por semana por:
• Persona
Diego BastianiJavier de Prado
Ignacio VignoloAlberto Martinucci
Agustin MullinMaximiliano Mañay
Ma. Emilia SilveiraLissette Colina
Roberto PertusaFederico Orihuela
Gabriela RodriguezVirginia Rodriguez
Lorena CalvoRaúl Rivarola
Marcos Suiffet
0
5
10
15
20
25
30
Promedio de horas por integrante
Horas
Promedio de horas por semana por:
Promedio de horas por semana por:
Productividad
Tamaño del Producto: 32281 LOCs Horas de Implementación: 1620 Horas totales del proyecto: 4020
Productividad de Implementación: 19,92 locs/hora
Productividad del Proyecto: 8,03 locs/hora
Verificación
Tipo de pruebas realizadas
Dificultades del testing
Herramientas
Cantidad de errores remanentes
Verificación - Tipo de pruebas realizadas
Pruebas unitarias y de integración (realizadas por los implementadores)
Pruebas de funcionalidad Escenarios condición Valores límite Exploratorias
Prueba de integridad de los datos Pruebas de interfaz de usuario Pruebas de documentación Pruebas de regresión
Verificación - Dificultades
Configuración del ambiente de testing
Atrasos en la implementación
Recursos compartidos con otros roles
Verificación - Herramientas
Reporte de incidentes: Mantis Necesaria Gratuita Sencilla
Verificación - Resultado
Cantidad de pruebas ejecutadas 321 Incidentes reportados 86 Incidentes remanentes de los reportados 5 menores
Incidentes reportados
0
5
10
15
20
25
30
semana 11 semana 12 semana 13 semana 14
Semanas
Can
tid
ad
Detectados
Catastroficos
Críticos
Marginales
Menores
SQA - Estrategia
Definición de atributos de calidad relevantes para el producto: Enfasis en la interfaz gráfica. Facilidad de uso, interfaz intuitiva.
Definicion de estandares de documentación.
Revisión de las entregas semanales.
Revisiones específicas enfocadas en los objetivos de cada fase.
Revisiones de la aplicación enfocadas en el aseguramiento de la calidad.
SQA – Dificultades y Logros
Dificultades: Curva de aprendizaje del proceso. Coordinación de las entregas. Realización de revisiones técnicas formales.
Logros: Identificación temprana de dificutades para el
cumplimiento de los objetivos de cada fase. Aseguramiento del nivel general de calidad de la
documentación. Aseguramiento de la calidad del producto.
SCM
Uso del repositorio para la gestión de documentos, fuentes y ejecutables a través de la herramienta SVN Subversion 1.6.4 con cliente Tortoise
Se definió una nomenclatura de códigos para la identificación de los elementos
Se definió la Línea base realizándole auditorias para corregir errores y mantener la estabilidad permitiendo así la trazabilidad de los elementos
Estrategias de Branching: Branch por Componentes Por cada ralease y/o entrega se crearon Tags Seguimiento y control de bugs mediante la herramienta Mantis y
se aplicaron políticas de respaldo y pruebas de Plan de contingencia
SCM - ¿Qué se pudo haber hecho mejor?
Por momentos se sufrió de Big Bang Merge (aplazar la fusión) y en algunos componentes de Merge-Paranoia (evitarla).
La creación del ambiente de pruebas demoró más de lo deseado .
Se hubieran obtenido mejoras en temas puntuales si se hubieran usado correctamente:
Tree Conflict DotProyect.
Relación con el Cliente
Responsable de Comunicación fue el nexo entre Cliente y Grupo
Muy buena retroalimentación de ambas partes
A lo largo del proyecto la relación con el mismo fue correcta
Evaluación del proceso seguido
En un principio: Sobre esfuerzo por cumplir con los plazos pedidos Gran volumen de documentos y poca información Repetición de información en documentos
Mediando el proyecto hasta el final: Priorizar entrega de docuementos El grupo comprende que el MUM es una guía flexible
Conclusiones
El grupo siempre estuvo muy unido y enfrentó las dificultades que se plantearon en el proyecto, de manera de buscar la mejor solución para las mismas y seguir avanzando fase tras fase
Se obtuvo como resultado un producto con cierto grado de verificación y calidad aceptables con su respectiva documentación
Una buena experiencia de aprendizaje para todos los integrantes del grupo y nos acerca y nos prepara para la vida profesional
Top Related