El documento presenta el Modelo Controlado para Código Abierto (MOCCA), el cual define etapas y métricas para el desarrollo de software de código abierto. Se aplicó MOCCA en el proyecto OpenASEL con 6 desarrolladores voluntarios. Aunque no se liberó un prototipo estable, el modelo provee una guía valiosa para estandarizar el proceso de desarrollo de software de código abierto.

1. Alejandro Moreno Célleri
Luis Galárraga del Prado

2.  Introducción
 Objetivo
 MOCCA (Modelo Controlado para Código
Abierto)
 Aplicación de MOCCA: OpenASEL
 Análisis de Resultados
 Conclusiones

3.  Métodos y herramientas evolucionan con el tiempo
 Eficiencia
 Ingeniería de Software
 “Una disciplina que comprende todos los aspectos de la
producción de software desde las etapas iniciales de la
especificación del sistema, hasta el mantenimiento de éste
después de que se utiliza”
 Orientado al software privativo (Modelo Catedral)

4.  FOSS (Free Open Source Software)
 Reducir brecha digital
 Modelo de procesos para FOSS?
 Idea general
 Ciertos lineamientos, sugerencias, características
 En la práctica, cada proyecto utiliza su modelo
 Modelo Bazar
 No es un modelo per se

5.  Definir un modelo de desarrollo estilo Bazar, el
mismo que es frecuentemente utilizado en los
proyectos de FOSS, teniendo en consideración
las diferentes variantes que se pueden
encontrar de este modelo y tratando de adoptar
las ideas más relevantes y actuales.
 Evaluación a fin de comprobar su validez como
solución al problema

6.  No tener un modelo de procesos estandarizado
 Muchas personas no se arriesgan
Grandes empresas
Inversión Riesgos

7.  Etapas de MOCCA
 Definición de aspectos iniciales
 Análisis y diseño de la solución
 Implementación
 Proceso de estabilización
 Liberación del producto
 Características Principales
 “Libera a menudo, libera rápido”
 “Dados suficientes ojos, todo error es superficial”

9.  El estilo bazar no es considerado como una
metodología viable
 Ausencia de mecanismos de control de calidad
 Medición de la salud del proceso
 Métricas del proceso
 Frecuencia de liberaciones, correos enviados, conflictos, etc
 Métricas del producto
 Número de bugs reportados por release, descargas, etc

10.  Aplicación para la administración de seminarios o clases a
distancia
 Interfaz web
 Soporte para videoconferencia, mensajería instantánea, recursos
compartidos (archivos) y presentaciones con pizarra compartida
 InterfazWeb de Administración
 Django
 Servidor y Cliente OpenASEL
 AccessGrid 3.1

11.  Ambiente de desarrollo
 Imperativo desarrollar la aplicación en un ambiente
colaborativo
 Ayuda del grupo KOKOA (Comunidad de Software Libre
de la ESPOL)
 La comunidad estuvo compuesta por 6 desarrolladores.
 Herramientas de soporte para la toma de
métricas

14.  El principal objetivo del modelo es garantizar en cualquier
momento información certera sobre la salud del proceso a fin de
tomar las medidas del caso para encaminarlo al éxito
0
0.5
1
1.5
2
2.5
3
3.5
22/02/08 13/03/08 02/04/08 22/04/08 12/05/08 01/06/08 21/06/08
Promedio
diario
de
emails
enviados
Tiempo
Actividad en la lista de correos
En el período del 29 de febrero al 16 de junio
Actividad

15. -5%
0%
5%
10%
15%
20%
25%
30%
22/02/08 13/03/08 02/04/08 22/04/08 12/05/08 01/06/08 21/06/08
Tasa
de
commits
erróneos
Tiempo
Tasa de aportaciones erróneas en el tiempo
En el período del 29 de febrero al 16 de junio
Actividad
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
22/02/08 13/03/08 02/04/08 22/04/08 12/05/08 01/06/08 21/06/08
Promedio
diario
de
mensajes
de
foro
Tiempo
Actividad en el foro de discusión
En el período del 29 de febrero al 16 de junio
Actividad

16. 77%
22%
1% 0%
Cambios realizados en el repositorio por desarrollador
Hasta la última revisión y medido por el número de cambios en los
archivos del repositorio
Desarrollador 1
Desarrollador 2
Desarrollador 3
Desarrollador 4
Desarrollador 5
Desarrollador 6
Actividad en la lista de correos por usuario
Medida en número de correos, entre el 29 de febrero y el 16 de junio
Colaborador
Desarrollador
Colaborador
Colaborador
Desarrollador
Líder
Colaborador
Líder
Desarrollador
Desarrollador
Colaborador

17.  Pleno conocimiento del estado del proyecto en el tiempo
 Información contextual es necesaria en el análisis
 Descensos en las métricas no implican apatía
 No todas las métricas definidas en el modelo sirven para todas
las instancias del mismo.
 Quienes colaboran, en muchos casos, lo hacen de forma
voluntaria
 Identificar un caso de apatía de parte de los miembros
 Elaborar planes de riesgo
 Comunidad motivada + canales efectivos de difusión
 Buenas señales de progreso

18.  El modelo propuesto es válido en gran parte
 No logramos liberar un prototipo estable (pre-alphas)
 Motivos externos al modelo + problemas inherentes al
desarrollo voluntario
 El modelo es un gran paso hacia la
estandarización del proceso de desarrollo de
software libre
 Leves mejoras pueden ser aplicadas