| Resumen
|
Aunque el software libre no está necesaria … Aunque el software libre no está necesariamente asociado con un proceso de desarrollo software específico, existe una amplio consenso sobre los procesos más comunes que se utilizan. Esto no quiere decir que no existan proyectos de software libre que hayan sido creados utilizando procesos clásicos como el modelo en cascada. Generalmente el modelo de desarrollo en proyectos de software libre suele ser más informal, debido a que gran parte del equipo de desarrollo realiza esas tareas de manera voluntaria y sin recompensa económica, al menos directa, a cambio.
La forma en la que se capturan requisitos en el mundo del software libre depende tanto de la edad como del tamaño del proyecto. En las primeras etapas, fundador de proyecto y usuario suelen coincidir en una misma persona. Más adelante, y si el proyecto crece, la captura de requisitos suele tener lugar a través de las listas de correo electrónico y se suele llegar a una clara distinción entre el equipo de desarrollo - o al menos los desarrolladores más activos - y los usuarios. Para proyectos grandes, con muchos usuarios y muchos desarrolladores, la captura de requisitos se hace mediante la misma herramienta que se utiliza para gestionar los errores del proyecto. En este caso, en vez de hablar de errores, se refieren a actividades, aunque el mecanismo utilizado para su gestión es idéntico al de la corrección de errores (se la clasificará según importancia, dependencia, etc. y se podrá monitorizar si ha sido resuelta o no). El uso de esta herramienta para la planificación es más bien reciente, por lo que se puede observar cómo en el mundo del software libre existe una cierta evolución desde la carencia absoluta a un sistema centralizado de gestión ingenieril de actividades, aunque indudablemente éste sea bastante limitado. En cualquier caso, no suele ser común un documento que recoja los requisitos tal y como es normal en el modelo en cascada.
En cuanto al diseño global del sistema, sólo los grandes proyectos suelen tenerlo documentado de manera exhaustiva. En el resto de proyectos, lo más probable es que el o los desarrolladores principales sean los únicos que lo posean -a veces sólo en su mente-, o que vaya fraguándose en versiones posteriores del software. La carencia de un diseño detallado no sólo implica limitaciones en cuanto a la posible reutilización de módulos, sino que también es un gran hándicap a la hora de permitir el acceso a nuevos desarrolladores, ya que éstos se tendrán que enfrentar a un proceso de aprendizaje lento y costoso. El diseño detallado, por su parte, tampoco está muy generalizado. Su ausencia implica que se pierdan muchas posibilidades de reutilización de código.
La implementación es la fase en la que se concentra el mayor esfuerzo por parte de los desarrolladores de software libre, entre otras razones por que a ojos de los desarrolladores es manifiestamente la más divertida. Para ello se suele seguir el paradigma de programación clásico de prueba y error hasta que se consiguen los resultados apetecidos desde el punto de vista subjetivo del programador. Históricamente, raro es el caso en el que se han incluidas pruebas unitarias conjuntamente con el código, aún cuando facilitarían la modificación o inclusión de código posterior por parte de otros desarrolladores. En el caso de algunos proyectos grandes, como por ejemplo Mozilla, existen máquinas dedicadas exclusivamente a descargarse los repositorios que contienen el código más reciente para compilarlo para diferentes arquitecturas [reis:mozilla:02]. Los errores detectados se notifican a una lista de correo de desarrolladores.
Sin embargo, las pruebas automáticas no están muy arraigadas. Por lo general serán los propios usuarios, dentro de la gran variedad de usos, arquitecturas y combinaciones, los que las realizarán. Esto tiene la ventaja de que se paralelizan a un coste mínimo para el equipo de desarrollo. El problema que plantea este modelo es cómo organizarse para que la realimentación por parte de los usuarios exista y sea lo más eficiente posible.
En cuanto al mantenimiento del software en el mundo del software libre -refiriéndonos con ello al mantenimiento de versiones antiguas-, es una tarea cuya existencia depende del proyecto. En proyectos donde se requiere una gran estabilidad, como núcleos del sistema operativo, etc., se mantienen versiones antiguas del proyecto, ya que un cambio a una nueva versión puede resultar traumático. Pero, por lo general, en la mayoría de los proyectos de software libre, si se tiene una versión antigua y se encuentra un error, los desarrolladores no suelen ponerse a corregirlo y aconsejan utilizar la versión más moderna con la esperanza de que haya desaparecido por el hecho de que el software ha evolucionado. hecho de que el software ha evolucionado.
|
