EL CATEDRAL Y EL BAZAR

EL CATEDRAL Y EL BAZAR

El modelo catedral y bazar fue escrito por el autor Eric S. Raymond en mayo de 1997 en un congreso sobre GNU/Linux en Bavaria.

En donde no s habla acerca de los construcciones de los catedrales están basadas por jerarquías que aprovechan para construir o desarrollar programas y que cuenta por un líder que dirige los procesos.

Dentro del modelo catedral están formados por un pequeño grupos de desarrolladores ya que es un entorno cerrado, las tareas que desempeñan los desarrolladores son a bases de roles que están perfectamente definido.

El estilo catedral en el estilo catedral el desarrollo de software está dirigido de manera centralizada y el proceso de desarrollo está restringido o un grupo de programadores quienes trabajan fuertemente en la depuración del código con la finalidad de que los usuarios pueden ver menos errores en cada versión liberada.

Consideremos el catedral como modelo básicamente para algunos desarrolladores consta que su código no se puede ser visible para los demás y dentro de esto queda restringido que solamente los desarrolladores pueden corregir a los errores.
Características del modelo catedral:
• Modelo típico de desarrollo de software propietario.
• Método clásico y un entorno cerrado
• Pequeños grupos de desarrolladores lideres.
• Modelo típico de aplicaciones que siguen modelos tradicionales de cascada o espiral
• Tareas y roles bien definidas según el proyecto.
• Se distinguen por 3 grupos de persona.
1. Los dedicados al diseño del sistema.
2. Los dedicados ingenieros.
3. Los implementadores.

EL MODELO BAZAR
El modelo bazar es un entorno abierto en donde cualquiera pueda participar, también dentro del bazar no hay lideres claros y puede tener un numero de desarrolladores indeterminados y puede liberar rápido y a menudo.
El estilo bazar: Crea una comunidad de programadores cada uno con sus propios intereses y agendas, a modo de un “bazar” oriental

Principios
● Trate a los usuarios como colaboradores, es la forma más rapida de mejorar el código y la más efectiva de depurarlo.
● Liberar rápido, Liberar seguido. Y escucha a tus clientes.
● Mantener varias versiones.
● Dada una base suficiente de desarrolladores asistentes, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.
● Lo mejor, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
● La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.

A continuación se explica más concretos los puntos anteriores:
1. Existe una ingente cantidad de personas en su elaboración y cuantos más mejor.
2. En el momento en el que se puede publicar una versión se hace, aunque esté muy incompleta.
3. Los errores se encuentran con facilidad porque hay muchas personas trabajando simultáneamente en ello. Su descubrimiento se pone en marcha desde el principio.
4. El código es abierto, o lo que es lo mismo, cualquiera puede leerlo y modificarlo.
5. La estructura organizativa es difusa, hay una serie de normas para participar pero no una jerarquía claramente definida. Una persona puede contribuir durante toda la vida del proyecto o de un modo fugaz.

El modelo bazar son las siguientes conclusiones que hay que saber para sus aplicaciones:

1. Todo trabajo de software comienza a partir de las necesidades personales del programador. No es lo mismo trabajar para un proyecto a cambio de un salario que trabajar gratis en algo en lo que se encuentra una satisfacción personal o se cubre una necesidad. Lo segundo motiva más.
2. Los buenos programadores saben que escribir. Los mejores que reescribir (y reutilizar). Es más fácil partir de una solución aunque sea incompleta y mala que de cero. Linus lo que hizo no fue construir un sistema operativo desde la primera línea de código hasta el final (probablemente aún estaría en ello), en lugar de eso, tomó como punto de partida Minix. Por tanto, una forma de iniciar un proyecto puede ser buscar un proyecto similar ya hecho y tomarlo como guía.
3. Contemple desecharlo, de todas formas tendrá que hacerlo. Al final todo el código de Minix fue reemplazado, pero mientras existió fue un armazón a partir del cual pudo ir cambiando partes. El código de partida no es importante, de hecho seguro que tiene un montón de errores y no es adecuado a nuestras necesidades, solo sirve para comprender el problema.
4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
5. Cuando se pierde el interés en un programa, el último deber es dejarlo en herencia a un sucesor competente.
6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
7. Publique rápido y a menudo, y escuche a sus clientes.
8. Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.
9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le responderán convirtiéndose en su recurso más valioso.
11. Lo más grande después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
13. La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
14. Toda herramienta es útil empleándose de la forma prevista, pero una ``gran'' herramienta es la que se presta a ser utilizada de la manera menos esperada.
15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y nunca eliminar información a menos que los receptores obliguen a hacerlo.
16. Cuando su lenguaje esté lejos de uno Turing-completo, entonces las ``ayudas'' sintácticas pueden ser su mejor amigo.
17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.
18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
19. Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerción, muchas cabezas serán, inevitablemente, mejor que una.

PROCESOS EN EL DESARROLLO DE SOFTWARE LIBRE

En el proceso de desarrollo de un software propietario se realiza mediante análisis, diseño, pruebas, implementación e implantación y lo que diferencia sobre software libre es el uso de la palabra kernel que tienen dos significado como grupo o núcleo se utiliza núcleo por haber derivado del núcleo minix y grupo porque están integrados por una comunidad.

Básicamente nos apoyamos acerca de las definiciones de kernel para los procesos en el desarrollo de software libre que a continuación describiremos.
Kernel se define como núcleo o grupos su visión de kernel está dada en que es u grupo el que lo conforma para la colaboración para el trabajo o actividades. Se analizan los ciclos de vida para el proceso de desarrollo de software.

k. Análisis k. Diseño
k. Planeación
k. Implantación k. Implementación
Comunidad libre

Esta pequeña figura en donde nos presenta unos ciclos de los procesos que muestra el kernel de planeación queda centrado por la cual está orientada a los demás kerneles a desarrollar sus propias actividades. Lo cual parte de análisis y llegando a la implantación de cada unos de los módulos, como vemos la comunidad libre queda fuera de los kerneles ya que la comunidad libre se refiere al grupo de personas que participan en actividades relacionadas con el análisis, diseño, implementación e implantación de aplicaciones de quienes manera voluntaria apoya cualquier labor que tenga algunos de los kerneles.

Crear sitio web

En la web se plasmaran los avances, tareas pendientes, tareas asignadas, personas responsables y los cronogramas de actividades fijando para el desarrollo total del proyecto. Mediante un líder quien será el responsable de la publicación, el acceso para la comunidad libre los participantes será controlado y sus aportes serán recibidos en un espacio designado.

• Nombramiento y funciones de los diferentes grupos o kerneles de trabajo
Los kerneles que se integraran tendrán funciones específicas y serán dirigidos por un líder.

Kernel de Análisis: nombrado kernel o núcleo porque está compuesto por una o varias personas que conforman la comunidad. Pero lo cual tiene un líder que guiara a las actividades de análisis y será quien publique los productos generados en este grupo en el sitio web de la aplicación. Sus funciones de kernel de análisis son las $
siguientes:

• 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 requerimiento del sistema.
• Crear los modelos o diagramas preliminares del análisis (diagrama de flujos de datos, diagrama de funciones, diagrama 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 cuales 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); y la responsabilidad de obtener los mejores modelos, poniendo a consideración de la comunidad libre, para captar sus aportes y recomendaciones. Sus funciones de kernel de diseño son:
• Generar los modelos físicos y lógicos
• Implementar el diseño inicial de la interfaz grafica de usuario.
• Recolectar los aportes colocados en el sitio web de la aplicación en cuanto al diseño con el fin de procesarlos y determinar cuales se tendrán en cuenta para su aplicación.

Kernel de implementación: en este proceso de kernel esta divida por subkerneles, por lo cual están organizados según su distribución, con el objeto de tener mayor cooperación interna dentro de cada unos de ellos y así poder enviar sus aportaciones al grupo planeador. Funciones de kernel de implementación son las siguientes:

• Crear los subgrupos de codificación, asignando de codificación por módulos, por formularios u otros métodos de división del trabajo de programación de la aplicación.
• Desarrollar y llevar a cabo el plan de pruebas alfa.
Kernel de implantación: Está compuesto por un grupo concreto de personas identificadas totalmente, por lo cual será encargado de poner a consideración del producto y capacitar al usuario final. Sus funciones de desarrollos son los siguientes:
• Generar y llevar a cabo el plan de pruebas beta del producto.
• Capacitar a la comunidad que utilizara la aplicación.
• Documentar los procesos que se llevaron a cabo en esta etapa.

Todos estos grupos o kerneles serán coordinados por un grupo denominado kernel de planeación, responsable de dar 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.

Bueno estos son los procesos que se beben de seguir para el desarrollo de software mediante los kerneles.