Aseguramiento de calidad en software libre
Rudy Godoy
Asociaci´ on Peruana de Software Libre
XIV CONEIS, Arequipa- Per´ u ago. 2005
Agenda
Calidad
Desarrollo de software libre
Calidad y software libre
Un caso de ´ exito: Debian
Agradecimiento
Calidad
Principios de desarrollo de software
Para un computador no existe concepto de c´ odigo bien escrito. Sin embargo, para nosotros, humanos, es importante puesto que puede tener consecuencias en el futuro.
¿Qu´ e buscamos?
I Facilidad de lectura.
I Facilidad de mantenimiento, prueba, depuraci´ on, correcci´ on, modificaci´ on y adaptabilidad.
I Baja complejidad.
I Bajo consumo de recursos.
I N´ umero reducido de alertas de compilaci´ on.
¿Est´ andares de calidad?
I ISO 15504
I
No define ning´ un est´ andar.
I
Se concentra en el modelo de capacidad de gesti´ on y definici´ on de procesos de las organizaciones.
I
Poca adopci´ on debido a costo elevado y contenido no est´ a disponible para descarga.
I CMM(I)
I
Documentos est´ an disponibles para descarga en forma gratuita.
I
CMM es promovido por el Dpto. de Defensa de EEUU y por esto tiene buena aceptaci´ on en la empresas.
I
CMMI ha reemplazado a CMM e incorpora muchas de las ideas de ISO 15504, pero mantiene los beneficios de CMM.
I
Herramientas y recomendaciones para asegurar calidad en
proceso de desarrollo
Desarrollo de software libre
Modelo
I Iniciativa personal o de empresa: Si algo te pica, ¡rascalo!.
I Versiones iniciales en condici´ on “beta”: Dejemos que la gente pruebe el software.
I Constante evoluci´ on: Publica con anticipaci´ on y frecuentemente.
I Aceptaci´ on o fracaso es relativo: Selecci´ on natural.
I Los programas est´ an creados bajo la filosof´ıa Unix: Interfaces claras e independientes del resto del sistema.
I Se entrega toda la documentaci´ on t´ ecnica al usuario: que es un potencial colaborador
I Se permite al usuario realizar las cosas como las desee o
necesite. Cambiar interfaz a su gusto.
Estado de proyectos
I Diversidad de aplicaciones de prop´ osito similar: Todos tienen cabida.
I Proyectos de una sola persona: No atrajo colaboradores o por su personalidad.
I Cientos de aplicaciones abandonadas: Voluntariado.
I Diversidad de enfoques t´ ecnicos o de programaci´ on: Mi lenguaje favorito es mejor, utilicemos ese.
I Nivel de conocimientos de desarrolladores es muy diverso:
Programas creados por personas que reci´ en aprend´ıan a programar.
I Problemas de licenciamiento: Xfree86, qmail, mplayer
Calidad y software libre
Mitos
I Software creado por voluntarios (l´ ease aficionados), debe ser malo.
I No se efect´ ua planeamiento de necesidades de los usuarios.
I No se utiliza nig´ un modelo de desarrollo.
I ¿Qui´ en me asegura que esto funciona como debe?.
I Los usuarios siempre quieren lo ´ ultimo.
I Los usuarios no son escuchados y no saben de que hablan.
Realidades
I Algunos de los voluntarios son: Richard Stallman, Guido Van Rossum, Alan Cox, Miguel de Icaza, Keith Packard. Tarea: a)
¿Qui´ en ha recibido un correo del desarrollador de su programa favorito? b) ¿Qui´ en ha escrito MS Word?
I Proyectos grandes reciben constante retroalimentaci´ on de los usuarios (bugzilla, debbugs, gnats).
I Los modelos de desarrollo, por ej. RUP, puede y es aplicado.
XP es lo m´ as cercano.
I Ning´ un tipo de software ofrece garant´ıas (ver licencias).
I ¿Cuantas personas conocen que todav´ıa utilizan Win9x, Win2k? (Cabinas)
I Todos los proyectos tienen por lo menos un medio para
comunicaci´ on.
Situaci´ on actual
I Proyectos principales est´ an realizando esfuerzos importantes de QA.
I Proyectos peque˜ nos tienen el apoyo de los integradores.
I Gran mayor´ıa carece de documentaci´ on sobre QA.
I Creciente preocupaci´ on por mejora en calidad y desempe˜ no (usuario).
I Coordinaci´ on de proyectos geogr´ aficamente dispersos.
I Poco inter´ es de comunidades locales en este aspecto.
Fortalezas y debilidades
Fortalezas:
I Revisi´ on de pares: Apertura de c´ odigo y colaboraci´ on.
I Documentaci´ on de procesos (est´ andares) y programas (APIs).
I Optimizaci´ on y mejora constante.
I Diversidad de opciones.
Debilidades:
I Proyectos m´ as grandes o interesantes atraen mayor cantidad de personas.
I Proyectos peque˜ nos o de pocas personas no siempre documentan procesos.
I R´ apida evoluci´ on a veces duplica o divide esfuerzos.
I Desarrolladores no utilizan entornos o programas que usuarios.
I Integraci´ on es a veces dificil por decisiones de cada proyecto.
Un caso pr´ actico: Debian
Debian y la calidad
El proceso de control de calidad en Debian empieza desde el momento que el software es empaquetado, pero no termina all´ı, es un proceso constante.
El control de calidad es la base fundamental del desarrollo de
Debian. No hacerlo nos lleva a tener incompatibilidades y
corromper el sistema.
Alcance del proyecto
I Desarrollo de un sistema operativo
I M´ as de 15,000 paquetes de software binarios
I Cerca de 11 arquitecturas de hardware soportadas
I M´ as de 900 desarrolladores en todo el mundo
I Basado en est´ andares, normas y constituci´ on
I Tres ramas de desarrollo
C´ omo se gestiona la calidad
I Un responsable (al 100%) por cada aplicaci´ on de software.
I Sistema de gesti´ on de fallos completamente p´ ublico
I
275,000 fallos registrados desde 1997. Abiertos cerca de 26,000.
I