El documento describe el proceso de Avancetec para adoptar OpenUP como su marco de procesos de desarrollo de software. Actualmente, el software producido no supera la mitad de las pruebas de calidad y la mayoría de errores son de criticidad media/alta. Tras evaluar alternativas como Waterfall y XP, se eligió OpenUP por ofrecer mayor equilibrio entre agilidad y disciplina. Se definieron roles, tareas, plantillas y patrones de capacidad para iteraciones cortas de identificación de requisitos, desarrollo de arquitectura

1. OPENUP COMO PROCESO DE
DESARROLLO DE SOFTWARE

2. NUESTRA EMPRESA ES AVANTEC
Y se dedica al desarrollo y mantenimiento de software

3. PROCESO DE TOMA DE DECISIONES

4. PLANTEAMIENTO DEL PROBLEMA
Indicadores de la situación actual
Casos de Prueba después de QC
El software producido no es
capaz de superar ni la mitad
37% de los casos de prueba de
Prueba exitosa
Prueba fallida
QC
63%
Criticidad de errores detectados
Criticidad baja Criticidad media Criticidad alta
La mayoría de errores tienen
un nivel de importancia 37%
26%
medio/alto
37%

5. ALTERNATIVAS DE SOLUCIÓN
Algunas metodologías

6. EVALUACIÓN TÉCNICA
Evaluación de alternativas
Criterios evaluados:
●
Gestión de requerimientos
Evaluación de Alternativas
●
Pruebas y criterios de 90
aceptación
85
●
Interacción con el usuario 80
●
Contenido de releases 75
Evaluación técnica
●
Definición de arquitectura 70
●
Soporte de herramientas 65
Waterfall XP OpenUP
●
Familiaridad del equipo
●
Complejidad en la
implementación

7. EVALUACIÓN ECONÓMICA
Evaluación de alternativas
Consideraciones:
●
Duración de 6 meses Evaluación económica
●
Tamaño de 20 KLOC 160000
140000
●
Un AF, un ARQ, 4 DEVS y 2 QC 120000
100000
●
Los errores requieren 25 horas 80000
60000
de DEV y 20 de QC 40000
20000
●
Incidencias por KLOC: 0
Waterfall XP OpenUP
●
Waterfall: 33.3 Costo de recursos Deuda técnica
●
XP: 0.75
●
OpenUP: 1.8

8. OPENUP ES NUESTRO
FRAMEWORK DE PROCESOS
Lo usaremos como base de nuestro proceso de desarrollo

9. MARCO TEÓRICO

10. ECLIPSE PROCESS FRAMEWORK
Marco Teórico
Permite definir metodologías con herramientas de ingeniería de
procesos. Provee EPF Composer que nos permite implementar,
desplegar y mantener procesos.

11. OPENUP
Marco teórico
Proceso Unificado ligero.
Iterativo, incremental y
extensible.
Incluye los roles Stakeholder,
desarrollador, arquitectos,
Jefe de Proyecto y Tester.
Tiene como objetivo la
disminución del riesgo,
identificando inconvenientes
temprano.
Busca balancear agilidad
con disciplina.

12. DESARROLLO DE LA SOLUCIÓN

13. METODOLOGÍA
Definición del nuevo proceso de entrega
Definición de Contenido del método:
Roles, Tareas, Plantillas y Productos
de Trabajo.
Asignar responsabilidades a los roles
sobre productos de trabajo.
Definir plantillas y guías para
productos de trabajo y tareas.
Definición del Patrones de
capacidad.
Definición del Proceso de Entrega
Publicación del Proceso.

14. IDENTIFICAR REQUERIMIENTOS
Patrón de capacidad

15. DESARROLLAR LA ARQUITECTURA
Patrón de capacidad

16. DESARROLLAR INCREMENTO
Patrón de capacidad

17. PROBAR SOLUCIÓN
Patrón de capacidad

18. PROCESO DE ENTREGA
Para Aplicaciones Web en Avances Tecnológicos

19. EVALUACIÓN DE RESULTADOS
Indicadores del nuevo contexto
Casos de Prueba después de QC
El porcentaje de éxito
41%
aumentó de 37% a 59%
Prueba exitosa
Prueba fallida
59%
Criticidad de errores detectados
Criticidad baja Criticidad media Criticidad alta
El porcentaje de errores de 15%
8%
criticidad alta se redujo de
37% a 8%
77%

20. CONCLUSIONES
Palabras Finales
Implementar un proceso iterativo
incrementa la Calidad del Software.
La Planificación Iterativa para
intervalos cortos es muy precisa.
El proceso de desarrollo debe
soportar y aceptar los cambios en
los requerimientos.
Es necesario adaptar el proceso de
desarrollo al contexto de la
empresa.
El Proceso de Desarrollo no es
estático: está sujeto a cambios.

21. ¡GRACIAS!