Aseguramiento de calidad en software libre

(1)

Aseguramiento de calidad en software libre

Rudy Godoy

Asociaci´ on Peruana de Software Libre

XIV CONEIS, Arequipa- Per´ u ago. 2005

(2)

Agenda

Calidad

Desarrollo de software libre

Calidad y software libre

Un caso de ´ exito: Debian

Agradecimiento

(3)

Calidad

(4)

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.

(5)

¿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

(6)

Desarrollo de software libre

(7)

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.

(8)

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

(9)

Calidad y software libre

(10)

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.

(11)

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.

(12)

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.

(13)

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.

(14)

Un caso pr´ actico: Debian

(15)

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.

(16)

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

(17)

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

Clasificaci´ on de fallos (paquete, encargado, severidad).

I Equipo permanente de QA: BSP, MIA, WNPP, autobuild.

I Interacci´ on y cooperaci´ on con desarrolladores de aplicaciones.

I Reuniones de trabajo, principal: DebConf, otras: Odenburg, d-i, debian-es.

I Documentaci´ on de procesos: Empaquetado, NM, QA, buildd, etc.

I Constante prueba de funcionalidad: ftpmasters: buildd, dak,

desarrolladores: piuparts.

(18)

Presentaci´ on hecha con L ^A TEX beamer en un sistema Debian

Rudy Godoy [email protected]