sábado, 13 de junio de 2009

La catedral y el bazar, Procesos del software libre

LA CATEDRAL Y EL BAZAR

La Catedral y El Bazar* Este escrito fue presentado por Raymond en mayo de 1997, en un congreso sobre GNU/Linux en Bavaria.
El modelo catedral se maneja por sólo unos cuantos programadores denominados genios y trabajan horas y horas encerrados y sólo ellos tienen acceso al programa o código, ellos no dejan que nadie contribuya con el mejoramiento del desarrollo del software.
Se le da el nombre de catedral por que sigue un modelo jerárquico, se simula como una construcción de una catedral por que en ella participan personas que solo tienen un rol definido y solo pueden realizar ese trabajo y nada más.
El modelo del bazar es importante puesto que con este modelo se desarrolló una revolución de programar o de crear código libre en el que cualquiera pudiera contribuir para el mejoramiento de los programas informáticos existentes en las empresas u organizaciones; de esta revolución de crear y desarrollar código apareció el programa Linux y se ha creado buenas ideas para la ingeniería del Software, Linux fue creado por miles de hombres programadores de todo el mundo llamados Hacker, este nombre se hereda de la necesidad de cambiar el modelo de programación que antes se utilizaba, llamado el modelo de la catedral. Estos hombres desarrolladores se comunicaban o se comunican utilizando la interfaz de la Internet, estos hombres estudiaron, aprendieron y aplicaron el modelo del bazar para el funcionamiento de Software Libre. Estos programadores empezaron sus prácticas de desarrollo cuando tenían tiempos libres, es por eso que nace el nombre de Software Libre. El bazar es como considerado como un mercado sobreruedas por que todos pueden aportar o adquirir lo que necesitan por ser libre.
Lecciones enumeradas en La Catedral y el Bazar de Eric S. Raymond

1. Todos los trabajos buenos en software comienzan tratando de paliar un problema personal del que los programas.
2. Los buenos programadores saben qué escribir. Los mejores, qué reescribir (y reutilizar).
3. Piensa en desechar al menos uno: lo terminarás haciendo de todos modos.
4. Si tienes la actitud adecuada, los problemas interesantes te encontrarán.
5. Cuando un programa deja de interesarte, tu último deber es pasarlo a un sucesor competente.
6. Tratar a tus usuarios como colaboradores es el camino menos complicado para mejorar con rapidez y depurar eficazmente un programa.
7. Lánzalo pronto. Lánzalo a menudo. Y escucha a tus usuarios.
8. Dada una base lo suficientemente amplia de probadores y colaboradores, casi todos los problemas se identificarán con rapidez y su solución será obvia para alguien.

9. Estructuras de datos inteligentes asociadas a un código torpe funcionan mucho mejor que la alternativa opuesta.
10. Si tratas a la gente que te ayuda a depurar un programa como si fueran tu recurso más valioso, responderán convirtiéndose en eso precisamente.
11. La siguiente cosa mejor que tener buenas ideas consiste en reconocer las buenas ideas de tus usuarios. Y en ocasiones ésta última es la mejor en términos absolutos.
12. A menudo, las soluciones más sorprendentes e innovadoras surgen al darte cuenta de que la idea que se tenía del problema estaba equivocada.
13. La perfección (de un diseño) no se consigue cuando no queda nada por añadir, sino más bien cuando no resta nada por eliminar.
14. Toda herramienta debe resultar útil en la forma prevista, pero una gran herramienta te lleva a usarla para realizar cosas jamás pensadas.
Cuando escribas programas que actúen como pasarelas de datos (gateway software), ten cuidado de modificarlos lo menos posible; y nunca elimines información a menos que su destinatario te fuerce a hacerlo.
15. Si el lenguaje de tu programa no es Turing-completo ni por asomo, puede venir bien endulzar su sintaxis.
16. Un sistema es sólo tan seguro como su secreto. Cuidado con los falsos secretos.
17. Para resolver un problema interesante, comienza por encontrar uno que lo sea para tí.
18. Si el coordinador de un proyecto tiene a su disposición un medio de comunicación al menos tan potente como Internet, y sabe cómo conducir a la gente sin coaccionarla, muchas cabezas son inevitablemente mejor que una.

PROCESOS DEL SOFTWARE LIBRE

El término kernel significa núcleo o grupo, el primer termino se refiere a núcleo por que fue desarrollado por el núcleo de minix y en segundo termino que es grupo por que esta conformada por una comunidad que aportan o dan ayuda para la elaboración de un proyecto. Es por eso que La visión de kernel está dada en que es un grupo el que lo conforma, pero puede tener aportaciones valiosas a su alrededor, y allí es donde se evidencia el trabajo colaborativo o en comunidad, haciendo que cualquier aporte hecho fuera del grupo pueda ser compilado en su interior, con el fin de enriquecer el producto final.

Donde el kernel de planeación orienta a los demás kerneles en un perfecto engranaje y estos a su vez desarrollan sus propias actividades, dando su inicio a cada una de las iteraciones en el análisis y llegando a la implantación de cada uno de los módulos. Al finalizar cada iteración pasa nuevamente al análisis de otro de los módulos. Se observa además como la comunidad libre se encuentra fuera de la integración de los kerneles, ya que ésta es la que da sus aportes y punto de vista al grupo general de trabajo (aporta a cada uno de sus kerneles cuando sea el caso).
También el término ‘comunidad libre’ juega un papel importante en este tópico; se refiere al grupo de personas

Los kerneles que se integrarán tendrán funciones específicas y serán dirigidos por un líder nombrado por estos, quien hará las veces de vocero oficial de cada núcleo en las reuniones generales del proyecto. Los kerneles son:
Kernel de análisis: nombrado kernel o núcleo porque está compuesto por una o varias personas que conforman la comunidad. Su líder guiará las diferentes actividades de análisis y será quien garantice la publicación de los productos generados en este grupo en el sitio web de la aplicación.

• Recolectar información relevante para el proyecto, haciendo uso de las diferentes técnicas de levantamiento de información (entrevistas, encuestas, documentación histórica).
• Generar el documento de requerimientos del sistema.
• Crear los modelos o diagramas preliminares del análisis (diagramas de flujos de datos, diagramas de funciones, diagramas de actividades o en orientación a objetos casos de uso).
• Recolectar los aportes colocados en el sitio web de la aplicación, en cuanto a análisis del problema, con el fin de procesarlos y determinar cuáles se tendrán en cuenta para su implementación.

Kernel de diseño: debe estar compuesto por un número limitado de miembros (dependiendo del volumen del proyecto); realizará las tareas de modelado lógico y físico de la aplicación y tendrá la responsabilidad de obtener los mejores modelos, poniéndolos a consideración de la comunidad libre, para captar sus aportes y recomendaciones.

• Generar los modelos lógicos y físicos.
• Implementar el diseño inicial de la interfaz gráfica de usuario.
• Recolectar los aportes colocados en el sitio web de la aplicación, en cuanto a diseño, con el fin de procesarlos y determinar cuáles se tendrán en cuenta para su aplicación.
• Generar la documentación que se desprende de cada actividad del diseño.

Kernel de implementación: se divide en varios subkerneles, organizados según su distribución geográfica, con el objeto de obtener mayor cooperación interna dentro de cada uno de ellos y así poder enviar sus aportaciones al grupo planeador, coadyuvando a que los productos que salgan de un lugar específico (ciudad, departamento, país, continente) sean de alta calidad y puedan ser publicados en la web y puestos a disposición de los demás equipos de trabajo.

• Generar estándares de codificación y construcción de las interfaces, es decir, plantillas que busquen la unificación de criterios de programación; para esto se sugiere la implementación y uso de patrones de diseño.
• Generar la codificación del producto.
• Desarrollar y llevar a cabo el plan de pruebas alfa.
• Generar la documentación que se desprende de la

Kernel de implantación: compuesto por un grupo concreto de personas identificadas totalmente, pues será el encargado de poner a consideración el producto y capacitar al usuario final.

• Instalar la aplicación desarrollada.
• Generar y llevar a cabo el plan de pruebas beta del producto.
• Capacitar a la comunidad que utilizará la aplicación.
• Documentar los procesos que se llevaron a cabo en

Todos estos grupos o kerneles serán coordinados por un grupo denominado Kernel de Planeación, responsable de dar el visto bueno para el arranque y finalización de las actividades de la comunidad de cooperación libre y de certificar la liberación al mundo del producto final.

Kernel de planeación:
• Mantener el sitio web.
• Coordinar las tareas de inicio y finalización de actividades.
• Elaborar el cronograma de actividades para el ciclo de desarrollo del producto de software libre.
• Asignar los controles de acceso al sitio web de la aplicación a los diferentes grupos de trabajo.
• Coordinar tareas de empalme entre los diferentes grupos de trabajo.
• Definir cuál es el eje geográfico del dominio de la aplicación.
• Llevar el control de versiones del producto.
• Crear las políticas para actualizar el producto.
• Documentar los procesos en los que está relacionado.
• Liberar el producto para su uso.

No hay comentarios:

Publicar un comentario