2. Contenido
• Antecedentes y Motivación
• Necesidades, alternativas y solución
• Estudio de la naturaleza del proyecto
• La Calidad en el proyecto MOSKitt
• El Módulo de Soporte al Proceso gvMétrica
• Conclusiones
3. Antecedentes y Motivación
• gvPontis: Migración global a Sw Libre.
• gvMétrica: Metodología de Desarrollo
• Estandarizar el trabajo
• Incrementar de la calidad del software producido
• Mejorar la productividad del equipo.
✔
Proceso
✔ Roles
✔ Técnicas
✔ Métodos
✔ Recursos E/S
✔ Herramientas
4. Necesidades y Alternativas
Necesidad de una HERRAMIENTA
para aplicar GVMÉTRICA
Estudio de Viabilidad (2006)
Catálogo de Requisitos ➢ Herramientas Comerciales
➢ Funcionales:
➢ Editor UML2
➢ Editor de BBDD ➢ Herramientas Software Libre
➢ Repositorio de Modelos ....
➢ No Funcionales: ➢
Desarrollo propio
➢ Software Libre
➢ Entorno de Trabajo Colaborativo
➢ Basado en Estándares ?
5. Alternativas
• Modelos complejos e inconexos
Alternativa 1 -> Dificultades • Actualizar los modelos
• Inconsistencia en los modelos
• Modelos finalmente obsoletos
✔
Proceso
✔ Roles
✔ Técnicas
✔ Métodos
✔ Productos E/S
✔ Herramientas
6. Alternativas y Solución
• Basada en Eclipse y EMP
• DSL's, UML2, BPMN
Alternativa 2 -> Solución • Transformaciones M2M, M2T
• Modelos sincronizados
• Soporte al proceso
• Integración con el entorno de trabajo
Herramienta
✔
Proceso
✔ Roles
✔ Técnicas
✔ Métodos
✔ Productos E/S
✔ Herramientas
gvMétrica
Proyecto
7. Estudio de la Naturaleza
del Proyecto
● Proyecto en Software Libre que debe promover:
● La Colaboración con otros proyectos
● La Creación y Mantenimiento de una Comunidad
● Su Difusión y transparencia:
● código, documentación, planificación, avances, objetivos
● Unos Canales de comunicación claros:
● Internos y Externos
● Visibilidad de cuál es la Estructura del proyecto
8. Estudio de la Naturaleza
del Proyecto
● Principal Riesgo:
Complejidad para determinar el Alcance del Proyecto:
● Gran envergadura.
● Alto grado de incertidumbre tecnológica.
● Alto componente Investigador.
● Dificultad para encontrar personal con experiencia/preparación.
9. Estudio de la Naturaleza
del Proyecto
● Es necesario el Seguimiento y Control:
● Relación contractual:
● Hay que cumplir con plazos, costes, objetivos.
● Informe periódico de Seguimiento a la CIT y a las empresas que
colaboran.
Para minimizar los riesgos se necesita asegurar:
La Calidad en el Proyecto
10. La Calidad en el proyecto
Mejorar la Calidad desde 4 frentes:
• el Proceso de Desarrollo
• la Gestión del Proyecto
Soporte a
• la Gestión de la Configuración gvMétrica
• el Plan de Pruebas del Proyecto
Planes
Específicos
Planes
Marco
11. La Calidad en el proyecto
Desde el Proceso de Desarrollo
● Metodología de Desarrollo: adaptar gvMétrica+.
● Contínuos Estudios de Viabilidad.
● Desarrollo por Versiones:
● 1 versión cada 4 meses Revisión del Alcance
● Compartir el conocimiento (equipo/comunidad):
● Estandarización de los puestos de trabajo.
● Manuales para el desarrollador, Howto, CookBook
● Publicación
● Plan de formación (previsto)
12. La Calidad en el proyecto
Desde la Gestión de la Configuración
● Plan Específico Plan Marco de GC (gvMétrica+)
● Control de Versiones (svn)
● Control de Incidencias (gforge)
● Construcción Continua (Eclipse PDE (headless) – Hudson )
● Objetivo:
● Integración continua + Testeo
● Automatización de la construcción del RCP
13. La Calidad en el proyecto
Desde la Gestión del Proyecto
● Plan Específico Plan Marco (gvMétrica+)
● Planificación global (roadmap) Detallada por Iteración
● Planes: de Riesgos, de entregas, de Comunicación...
● Control y Seguimiento de las tareas (gforge) de una jerarquía de
proyectos definida por el diseño.
● Procedimiento: Tareas, Recursos generados y Roles bien definidos.
● Informe periódico de Seguimiento.
● Delegar/Compartir responsabilidades.
● Toma de decisiones cooperativa en los grupos de trabajo.
14. La Calidad en el proyecto
Desde el Testeo
● Plan de Pruebas Específico Plan Marco de Pruebas (gvMétrica+)
● Qué niveles: de componentes, de implantación y validación.
● Qué no probar: Código generado automáticamente.
● Qué probar: Editores gráficos, transformaciones M2M, M2T.
● Cómo probar: Guías de Diseño de Casos de Prueba.
● Qué Casos de Prueba ejecutar: MOSCOW.
● Quién debe probar: Desarrolladores y usuarios.
● Cuándo probar: Planificación (global/detallada).
● Registro Bugs (gforge): clasificar, priorizar, planificar y resolver.
15. La Calidad en el proyecto
Desde el Testeo
Ayer: Hoy:
Último mes iteración dedicado a Automatización de las pruebas:
pruebas ✔ Editores Gráficos
¡Pruebas de Regresión! ✔ Transformaciones
Mañana:
➢ Consolidar el Equipo de Pruebas
➢ Ampliar casos de prueba automáticos
➢ Ampliar la cobertura
➢ Usuarios: Sólo test de validación y usabilidad.
➢ Integración testeo + Construcción Continua
22. Soporte a gvMétrica
Definición del proceso: Dashboard (y 3)
Abrir Cheat Sheet Abrir Editor
Acciones
23. Soporte a gvMétrica
Ejecución del Proceso: Intérprete
•Intérprete del Dashboard:
• Instancias distintas de un Crear M.Proyectos
mismo proceso. Abrir Cheat Sheet
• Identificada la Tarea actual.
25. Conclusiones
● MOSKitt es un proyecto de Software que no sólo
libera Software.
● Si tienes un método, tienes las herramientas para
darle soporte.
Si no lo tienes.......prueba con el nuestro.
● Alcance de MOSkitt: tan lejos como podamos....