Este trabajo pretende ayudar a quienes se plantean realizar migraciones hacia el Software Libre en organizaciones en cuanto a las metodologías de desarrollo.
Presenta brevemente el concepto de Software Libre y los modelos de desarrollo emergentes en su construcción. Se plantean algunos patrones considerados claves para el desarrollo de Software Libre.
El trabajo apunta a numerosa bibliografía en la Web que puede ayudar a profundizar cada tema y a conseguir información técnica detallada de cada aspecto en consideración.
El Software Libre [FSF:DSL] expresa una ética condensada en las 4 libertades que definen las prácticas de sus comunidades: uso, inspección, modificación, distribución libre y en los derechos que sólo estas prácticas garantizan, a la: cultura, educación y comunicación libres [Hipatia:SM-04]. Prácticas que conforman una ética del trabajo muy diferente a la protestante capitalista de la era industrial [Merten:GHS-00,Himanen:EHE-02,Bard:NNP-03].
Su creación fué sustentada por Internet, quien fué construida en el proceso. Esta red es la que permite compartir y liberar el conocimiento en las actuales sociedades del conocimiento, que así deja de ser un bien escaso y puede fluir y reproducirse libremente.
Creado mediante una dinámica o metodología colectiva -práctica habilitada por las 4 libertades e Internet- permite a la comunidad de prosumidores3.1 participar en un marco solidario de construcción del conocimiento [Saravia:MH-01].
La metodología participativa con la que se construye habitualmente el Software Libre se reconoce como técnicamente superior [Ball:OMS-03] a las metodologías antiguas y tradicionales de la ingeniería del software que Raymond [Raymond:CB,Raymond:AUP-03,Raymond:MC] sindica como fuente de su fuerza. La comprensión de esta dinámica, su real alcance, características y uso en las comunidades de desarrolladores es fundamental para tener una visión completa del fenómeno del Software Libre.
Podríamos personificar en Stallman (FSF) vs. Raymond (OSI) la discusión sobre que es lo que más importa en el Software Libre, si la ética metafísica de sus libertades, o la dialéctica materialista (tanto comunista como capitalista) que lo afianza día a día en las comunidades y mercados del planeta. Pero más allá de ética versus conveniencia o de libertades y derechos versus realidades y prácticas, ambos aspectos están íntimamente vinculados y se refuerzan mutuamente.
Las comunidades del Software Libre han construido poderosas herramientas y técnicas. Internet y sus diversos protocolos son los más notorios derivados de este trabajo. Estas herramientas fueron y son cruciales y su crecimiento determina el presente y el futuro del software en el planeta. EL Software Libre se edificó y conformó a si mismo construyéndolas. 3.2Alrededor de cada desarrollo y creación, las comunidades de desarrolladores inventan protocolos y crean software.
Las comunidades suelen funcionar como meritocracias donde el que más trabaja más capacidad de conducir y decidir tiene. En última instancia los desacuerdos y conflictos se resuelven creando ``forks'' o nuevos proyectos derivados.
Muchos de los casos paradigmáticos del Software Libre se construyen mediante consorcios de organizaciones, empresas y personas que aportan recursos para sostener el esfuerzo. Así la mayoría de los aportes al último núcleo ``Linux'' fue realizado por trabajadores de corporaciones [Jackson:LCB-04].
Algunas de las estrellas típicas del movimiento son: las herramientas ``GNU'', por ejemplo el compilador ``GCC'', el núcleo ``Linux'' [LinuxK:SW,LinuxO:SW,LinuxC:SW], el servidor web ``Apache'' [Apache:SW], el servidor de archivos ``Samba'' [SAMBA:SW], el directorio ``Open LDAP'', el paquete de oficina ``OpenOffice'' [OpenOffice:SW], los escritorios ``KDE'' [KDE:SW] y ``Gnome'' [GNOME:SW], los motores de bases de datos ``MySQL'' [MySQL:SW] y ``PostgreSQL'' [Postgres:SW], y el navegador ``Mozilla'' [Mozilla:SW]3.3.
El movimiento de Software Libre ya nuclea más personas participando de su construcción que el software propietario trabajando3.4 para ello.
En los modelos tradicionales de desarrollo e ingeniería de software [Gibbs:SCC-94,Oreilly:I-05,Robles:IS-02] que funcionan para productos licenciados en forma propietaria, el proceso comienza con el análisis de las necesidades de los usuarios por analistas del negocio. El ingeniero de software recibe los requerimientos y prepara las especificaciones. El administrador del proyecto asigna tareas a los desarrolladores distribuyendo el trabajo según las especificaciones. Los desarrolladores escriben el código pasando por las etapas de desarrollo y se prueba hasta que se instala. El usuario certifica y aprueba la funcionalidad. Luego el grupo de desarrollo muta para ser una unidad de mantenimiento que corrige los problemas y genera modificaciones sobre demanda. Para una nueva versión se comienza el ciclo de nuevo.
La estructura de costos de uso de este software pasa por tres componentes: L (licencia), R (renovación y mantenimiento), S (soporte), donde R+S suele ser el 20% de L [Murugan:PSO-05].
Este modelo es lento, tiene altos costos iniciales y de mantenimiento, y el trabajo se repite innecesariamente múltiples veces, ya que todo debe reescribirse de nuevo o en caso contrario pagar licencias a los que lo hicieron antes.
Los desarrolladores están controlados estrechamente y suelen firmar acuerdos de no divulgación. Se dificulta el intercambio de información, lo que suele implicar represión en el lugar de trabajo. Preguntar es un disvalor, pues muestra lo que no se sabe y baja la posición del que pregunta, quien es considerado peste, pues pone en evidencia lo que no se conoce La lucha por el posicionamiento político suele depender de las relaciones y el manejo de las jerarquías verticales.
En los modelos participativos y comunitarios de desarrollo de software, utilizados generalmente para Software Libre, los administradores organizan el proyecto, y reclutan o aceptan colaboradores, técnicos, revisores, documentadores, especialistas y/o contribuidores esporádicos.
Apenas el proyecto ha creado una base funcional de tests y código, puede comenzar a recibir aportes de terceros, aunque no pertenezcan al grupo que tomo la iniciativa.
Es un modelo dinámico y colaborativo donde el conocimiento colectivo se expande exponencialmente.
Permite que una gran cantidad de personas se involucren eficientemente, sin caída del rendimiento ante el aumento de la escala, como en los proyectos propietarios. A pesar de ser visto como un sistema anárquico, permite un manejo profesional, seguro y apropiado, con mejoras continuas y manejo de calidad. Todos participan de todo el proceso, y no se forman cuellos de botella, pues si un aspecto parece detenido inmediatamente mas personas se abocan al problema.
El modelo participativo construye un cuerpo creciente de conocimiento reduce tiempo y costos. Existen grandes comunidades en línea de donde se obtiene soporte.
En cada proyecto se toma 1000 de la comunidad y se aporta 1 en retorno. Lo que funciona porque todos toman lo mismo -el conjunto- y aportan algo diferente.
Impacto sobre las metodologías de intercambio y la economía
El Software Libre no se constituye como un conjunto de productos. Lo que se ofrecen y demandan son servicios. El software suele estar disponible.
El proceso de adquisición de software es muy diferente cuando se usa Software Libre. O los equipos de la organización usaria lo instalan y lo usan, o se contratan equipos de personas a tal efecto. En este caso el producto es el tiempo del equipo de personas, no el software.
Cuando se piensa en Software Libre, no se puede pensar entonces en comparar ``productos'' de software para elegir y poner una larga lista de softwares propietarios y libres para evaluar, sino que se debe entrenar o ``adquirir'' un equipo y este tomará a su cargo la selección del conjunto de software apropiado, en muchos casos lo modificará, o pedirá su modificación. En muchos casos no hay fronteras claras entre el desarrollo y la instalación o adecuación.
Ideas, conceptos y principios para el desarrollo de software, redactado como un ``lenguaje de patrones'' [Alexander:ULP-77].
Patrones que reflejan parte de la cultura Unix; ``KISS: Keep it simple stupid''; el arte de hackear por placer, o programar; con las ideas que se han ido creando en la construcción y uso masivo de Internet.
Prácticas que han conformado la más grande aventura colectiva de la humanidad en cuanto a creación de conocimiento.
Los patrones no son absolutos, en algunos casos se adoptan unos y no otros. Algunos contradicen a otros.
Referencias: [Fogel:POS-05].
Comunidad y cultura a través de Internet.
Del modelo propietario donde cada proyecto es un comienzo a un modelo basado en un edificio creciente de experiencias compartidas. Con enorme potencial de trabajo en paralelo. Los proyectos pueden tardar semanas en tener programas útiles y no meses.
El equipo de desarrollo consiste en administradores, mantenedores, contribuidores de código, técnicos en heleases, revisores y testeadores, documentadores, etc.
Los administradores del proyecto controlan el almacenamiento del código en un sistema de control de versiones concurrentes como el ``subversion''.
Todo el equipo, ``el público'', ve los cambios y puede comentarlos. Todos pueden tener versiones y ``snapshots'' del código, probarlos y hacer sugerencias.
Las propuestas de código se envían al administrador del para su revisión y control. Este puede asignar a otro del equipo la tarea de revisión, o incluso compartirlo en una lista para su revisión por muchos. El código será testeado y revisado y si es aceptado incorporado al proyecto mediante el sistema ``subversion''.
Es permanente y constante el envío de mejoras, la revisión y eventual selección de las mismas para su incorporación..
Nadie tiene el control total. Todos tienen los ojos en el código y pueden comentar las acciones de los administradores.
Se trabaja mediante aproximaciones sucesivas e iterativas. Se establecen reuniones IRC (Internet Relay Chat) semanales, diarias o incluso permanentes. Se hacen preguntas y dan respuestas por correo. Se comparte información, código y protocolos por diversos medios. Se descubren y se forman especialistas. Y se publican y registran los proyectos en sitios web comunitarios.
Es una disciplina particular de manejar proyectos surgida de Internet. Una clave para el desarrollo del Software Libre consiste en que los equipos accedan y aprovechen Internet a fondo. Esto requiere buen y constante ancho de banda. Internet posee un enorme cuerpo de conocimiento para los desarrolladores. Entre otros los archivos con los ``RFC'' de la ``IETF'', las listas de correo de proyectos similares, grupos de google, etc.. Participar en los mismos, preguntar y responder, etc.. Internet es el ``help desk'' del desarrollo libre. Pertenecer a las listas de correo, grupos de noticias y foros adecuados es esencial.
Para que una organización adopte el Software Libre es fundamental:
El desarrollo participativo expresa valores entre los que están la máxima simplicidad posible, el diálogo abierto, la realimentación permanente, y el coraje para efectuar cambios.
Cuando se busca migrar una nueva actividad y se necesita para ello crear una gran cantidad de aplicaciones libres, es conveniente involucrar a la comunidad de desarrolladores independientes y habilitarlos económicamente. Tener un plan de acción concreto y pensar en que será lo que reciba la comunidad en contraparte. Así construir un modelo de relaciones económicas apropiadas [Chance:SSO-05] que sustente a esta comunidad de desarrolladores.
Es importante promover y ascender a los empleados que conozcan de Software Libre y colocar a los expertos preexistentes en los niveles jerárquicos apropiados para divulgar, promover y capacitar a los demás funcionarios en su uso y cultura.
Acciones ejecutivas:
Acciones normativas:
Instalar Software Libre en los hogares y pequeñas organizaciones sociales es un desafio particular. Es conveniente abordarlo con conceptos profesionales de campos como la Antropología y Ciencias Sociales.
Es un cambio humano y cultural. No se trata de cambiar algunas tecnologías por otras. Se habla de formatear cerebros, y no solo discos duros.
Este tipo de cambios sociales eran antes motorizados con la escuela. Ante la regresión o la inexistencia de la escuela como esquema de adoctrinamiento nacional y social en el Tercer Mundo, se deben buscar nuevas formas de accion social y nuevos agentes de cambios.
Se debe visualizar la inserción social de tecnologías apropiadas como un fenomeno integral y global que comprende entre otras a: las energías alternativas, la cocina alternativa, la informática alternativa -software libre-, los sistemas ambientales alternativos, etc.. Es un camino diferente a la via ``hippie'' de constituir pequeñas comunidades. Cambios globales para las mayorías y no aldeas o grupos especiales. Así el conocimiento libre puede abrazar a otras intereses y no sólo a los vinculados a las patentes medicinales y los trangénicos.
Todo tipo de cambio que transforma una tecnología que requiere grandes flujos comerciales y energéticos centralizados o con control centralizado, grandes inversiones y ganancias para grandes corporaciones por otra que pueda activarse localmente en cuanto a bienes y servicios aunque requiera información global.
Así conocimiento libre globalizado más flujos materiales y energéticos localizados, parece ser la consigna para salvar al planeta y a las sociedades humanas. Para terminar con la globalización neoliberal y el modelo de abrir fronteras para maximizar los flujos comerciales globales. Otra variedad del ``Pensar global, hacer local'' [Mitchell:ALA-99].
Definir si se establece que se usa Software Libre con exclusividad o si solamete se decide priorizar soluciones, programas y servicios basados en Software Libre que promuevan la optimización de recursos e inversiones en tecnología de información.
Garantizar la auditabilidad plena y la seguridad de los sistemas, respetando la legislación sobre privacidad y seguridad.
En muchos casos el Software Libre permite mejorar notablemente la seguridad, dando a la vez mayor libertad. El Software libre hace parecer al software propietario como un vector para transportar virus y otras alimañas. Hay muchos otros factores que hacen mas seguro al Software Libre, entre ellos la posibilidad de recompilar todo el software y no tener que mantener compatibilidad binaria con antiguos ejecutables.
Es conveniente el cambio de una política de seguridad basada en protecciones o barreras a otra basada en protocolos seguros por naturaleza en cada recurso. Salir del modelo de seguridad mediante la oscuridad. Terminar con la necesidad de poner cercos inútiles que castigan y restringen a quien no es necesario restringir, para que dejen de pagar los santos por los pecadores.
Durante la transición al Software Libre aparecerán nuevos proyectos y se estará en diversos grados de avance en relación a proyectos propietarios predefinidos. Se debe explicitar una política definida con los mismos y un mecanismo para definir excepciones.
Como mínimo se debe restringir el crecimiento de los sistemas preexistentes y nuevos basados en tecnología propietaria.
Se debe buscar interoperatividad con sistemas preexistentes heredados.
Se debe evaluar cuando migrar un sistema, usar el sistema anterior en una nueva base tecnológica, crear un nuevo sistema, etc..
Para la migración de los sistemas propietarios preexistentes se puede graduar la velocidad en relación con la capacitación.
Se puede pasar de una situación con islas de Software Libre, a otra donde existen islas de software propietario inmersas en un mundo de Software Libre.
Se debe liberar el software sobre el que se tengan derechos. No solo se debe hacer software libre sino también debe ser gratuito y debe ser liberado en forma universal. El modelo de negocios no pasa por el código sino por los servicios que se construyan sobre el mismo.
También es conveniente establecer que el software creado se libere bajo la GPL [Stallman:GPL] (comunitaria). Utilizar la licencia GPL [FSF:QC-98,Varios:CSC]3.5 permite crear una cultura solidaria sin vampirismo.
Cuando se liber software que antes era privativo se debe buscar problemas de patentes, copyright. 3.6
Es recomendable consolidar una organización como derecho habiente del código, aún del recibido desde terceros. Esto debe estar claro en las comunidades que participen del desarrollo.
Liberar el software preexistente es un hecho trascendente, debe ser enmarcado mediante una conferencia de la cabeza de la organización anunciando que todo el software del cual es derecho habiente sera liberado bajo la GPL [Stallman:GPL], en forma universal.
Esto se podrá hacer uno por uno, por parte de los responsables de cada software, y se irán disponibilizando en el sitio web respectivo.
Se puede dar un plazo a cada responsable, para que se evalúe: a) el estado del código fuente y lo preparen para publicar, b) retiren información confidencial que pueda existir en las mismas, c) evalúen si existe alguna incompatibilidad legal con la GPL [Stallman:GPL] y el código usado y sugieran otra licencia libre en tal caso.
En tres meses todas las aplicaciones debieran tener este trabajo concluido, salvo alguna excepción a ser evaluada.
Se evaluara cual aplicación debe ser mantenida para el actual nivel de uso y por lo tanto colocada en un sistema ``subversion'' y cual ya no se toca más el código y queda congelada.
Sea generoso en lo que se acepta en el proyecto, riguroso en lo que emite.
El ciclo de desarrollo suele ser el inverso al del modelo tradicional, con un modelo de recirculación permanente del tipo cascada.
Se debe testear todo permanentemente, lo primero a crear para cada funcionalidad son sus test.
Los programadores deben escribir test unitarios todo el tiempo. Estos deben correr sin problemas en todo el ciclo de desarrollo. Los usuarios pueden escribir tests probando que todo funciona.
El desarrollo es inducido por tests. Primero se escribe el test, luego el código. Hasta que todos los test se pasan no se da por terminada la rutina. Cuando los pasa y no hay mas test posibles, se considera esta lista. Programar nuevas funcionalidades implica realizar mas tests.
Los tests son la práctica de la calidad.
Se define y se escribe el código de los test que se van a usar. En las metodologías ágiles los tests son tan importantes como el código y se hacen primero, pues el trabaja principal consiste en que el sistema los pase.
Programar y codificar es el trabajo mas importante y relevante de todo proyecto. El núcleo y esencia del desarrollo de software.
El diseño se especifica en el código. La estructura se crea en el camino, es parte del código, primero se programa la funcionalidad esencial, luego se la pule, se la amplía y eventualmente refactorea.
Para determinar que codificar:
Es importante disminuir el tiempo en que los usuarios pueden empezar a aprovecharse del proyecto (rápido retorno de la inversión, victorias tempranas).
Esta etapa sigue sigue inmediatamente a la de desarrollo. Incluye los tests de integración y la creación de los de instalación.
El proceso siempre recomienza. Cada elemento lo realimenta. Se parte de la idea inicial y los tests. Cuando ya trabaja la primera funcionalidad útil, se libera el código y se reciben comentarios. Llegado a este punto se puede refactorear, imponer nuevas ideas y crear mas tests, en un proceso cíclico continuo.
Las nuevas ideas y los reportes de errores de los usuarios controlan el proceso.
Es el principal requerimiento de un proyecto de Software Libre.
Es conveniente preparar material para tener entrenamiento informal y referencia. El software libre ha sido creado por autodidactas en su mayor parte.
Realizar permanentemente auditorías tecnológicas y revisar el software con arquitectos y desarrolladores de alto nivel. Realizar las mejoras sugeridas al código o introducir las recomendaciones en un listado del tipo ``TO DO''.
Definir la política de compras de licencias de software. Realizar permanentemente auditorías contables, revisar compras para comprobar que se está cumpliendo la política de compras y que no se adquieren licencias propietarias sin control. Incorporar la cuestión de las licencias a las rutinas de auditoría de los organismos pertinentes.
Mantener un sistema de gestión tecnológico como (``Objetivos de Control de Información y Tecnologías Relacionadas'' COBIT [COBIT:OC-98,COBIT:MR-98,COBIT:PG-00,COBIT:RE-98,COBIT:PO-00,COBIT:AI-00,COBIT:ES-00,COBIT:M-00,COBIT:A-00]).
COBIT ha sido desarrollado como un estándar generalmente aceptado y aplicable a las buenas prácticas de seguridad y control en TIC. Lo que sigue da un breve pantallazo sobre las ideas de COBIT, para su efectiva aplicación utilice los materiales originales mediante auditores certificados.
Es la tarea principal y definitoria en la creación de sistemas. La herramienta y capacidad fundamental de un creador de sistemas es su capacidad y nivel como programador. Todo lo otro es secundario [Saravia:CDE-04].
La creación de software puede ser un arte [Knuth:ACP] y para ello debe ser creativo, inventivo y expresivo de la sensibilidad, no sólo una técnica, ni una ingeniería.
La elegancia y belleza del código es el principal criterio para su evaluación.
Al programar se comprende e instrumenta la cuestión original. Se clasifican con elegancia los posibles casos. El código puede mirarse en función de la belleza con que esta redactado.
La capacidad técnica del programador es fundamental en este sentido.
El destinatario del código es otro humano. El código fuente es una obra intelectual -no el binario, que es un subproducto-, debe ser escrito, pensando en que va a ser leído (y no sólo ejecutado por un computador).
Programar es la quinta esencia de la evolución. Es automatizar el pensamiento, o pensar en como se piensa y diseñar el pensamiento.
La creatividad es el mas escaso e importante de los recursos. Las ideas innovativas y generativas, tanto propias como de los interesados (usuarios) son lo que impulsa el ``progreso''.
Todo nuevo proyecto se debe basar en ideas originales, precisas y claras de que se quiere y porqué.
El software debe crearse para resolver problemas nuevos.
Cuando se debe crear un software diferente para tareas similares, se esta fallando en el enfoque del problema.
¿Que origina o impulsa la idea de la creación de un nuevo software y por ello impregnará todo el proyecto de desarrollo? ¿La demanda de un usuario o la genialidad de un creador que percibe un nuevo universo posible?
Se debe evitar reinventar la rueda cada vez, por ello la novedad y creatividad de la idea es lo mas importante para comenzar un proyecto, que sea clara, innovativa, que permita la creación artística.
No se trata de programar tareas repetitivas una y otra vez, sino en todo caso crear un lenguaje de especificación que permita contener casos particulares. La instrumentación de estos casos no será una tarea de desarrollo sino simplemente la adaptación e instalación de una instancia de la creación original.
Estos conceptos no deben impedir la creación de un nuevo software para realizar algo que otro ya hace, en tanto y cuanto se haga con nuevas ideas. La diversidad de software para una misma función es positiva. Una de las caracteristicas importantes del Sofware Libre es que mantiene para cada categoría distintos softwares similares, el propietario ha creado en cada categoría monopolios.
Para cada nuevo problema se debe pensar y crear un lenguaje con el nivel de abstracción suficiente para manejar todas las posibilidades de uso. De tal forma, cada nueva tarea del mismo estilo, se implementa configurando el software, usando un lenguaje de nivel descriptivo acorde a la tarea.
Programar es instrumentar un lenguaje que permita a partir de la descripción de las tareas hacer funcionar el sistema. Cada tipo de tarea requerirá una descripción específica única para todos los negocios similares.
Todos los restaurantes/puntos de venta/etc del mundo podrían usar el mismo software, configurado de manera particular.
Programar, analizar y diseñar son tareas inseparables.
A veces no se analiza, sino se diseña, lo cual siempre es preferible. Esto implica re-ingeniería [Ellison:SW], y nos da la oportunidad de inventar la mejor forma de llevar una actividad y no congelar en un sistema la forma en que se la lleva. Muchas veces la informatización es una gran oportunidad para repensar la actividad.
El diseño se expresa en el código. El código expresa el diseño. Cualquier descripción formal del diseño de un sistema, debe ser parte de su programación. Se debe diseñar con un lenguaje que instrumente este diseño en código ejecutable. Cuanto mayor nivel de abstracción mejor. Pero nunca se debe usar un lenguaje de descripción que no produzca el código, o no pueda ser compilado o interpretado.
Usar descripciones cortas, introductorias y no formales para explicar los conceptos claves. Usar gráficos y esquemas aclaratorios. No usar sistemas formales no codificables.
Diseñar, analizar, codificar y testear es programar.
Todos escriben código de acuerdo a reglas que enfaticen la comunicación.
Descrea de todos los que impulsan un único camino verdadero. La etapa de los estándares es la muerte de una tecnología. Cuando está suficientemente madura para ser estandarizada seguro que hay algo radicalmente mejor y nuevo en algún lugar.
Usar una tecnología estandarizada para un nuevo sistema es empezar demasiado tarde, para comenzar un nuevo proyecto busque las tecnologías emergentes, que serán maduras cuando su proyecto entre en producción. El mundo avanza muy rápido en desarrollo de software.
Se puede utilizar una metáfora simple y compartida sobre como trabaja el sistema para guiar el desarrollo. Plantee esquemas conceptuales definidos, por ejemplo el tablero de comandos personalizado
Ver Test más arriba en ``Ciclo de Desarrollo'', 3.4.
Utilice cuando corresponda los estándares del proyecto ``GNU'' (GNU no es Unix) [GNU:GCS-04] que fundó el software libre tal como lo conocemos hoy día y los de ``GNU/Linux'' [LinuxBase:SW,FHS:SW] que constituye el sistema operativo más usado. En particular en cuanto los programas deben ser multiplataforma, usar autoconf, etc.. También es importante apegarse a los estándares POSIX, w3c, y de GNU/linux [FreeStandars:SW], etc. en cuanto correspondan.
La mejor documentación sobre un sistema es un código bien redactado. El código es el lenguaje humano que describe lo que los sistemas hacen. Los compiladores e interpretadores se encargan de traducir esto a un lenguaje que las computadoras entiendan, pero debe entenderse que el principal destinatario de un código es un humano, los compiladores que se arreglen.
El código que para explciarse requiere textos en lenguaje natural, puede ser visto como un código de baja calidad y confuso.
Para crear un sistema se debe en primer lugar comprender, probar y hacer interactuar todas las tecnologías que se piensan usar. Se deben construir tests para probar que funcionan como se piensa.
Los test se aplicaran a los primeros módulos que se vayan construyendo para utilizar las tecnologías en su bajo nivel. La tecnología determina e impacta profundamente en los diseños por lo que cualquier esfuerzo en clarificar estas interfaces repercute enormemente en todo lo que se haga a posteriori. Con las primeras versiones de estos módulos se puede comenzar a programar los sistemas deseados, implementando tests de los mismos en paralelo con su desarrollo.
Se debe probar que se conocen sus límites de capacidad y rendimiento.
Los errores deben ser controlados por un sistema de alto nivel manejado por política [Jungman:ECC], esta debe decidir que hacer ante cada error. Así se debe actuar diferente si el error se encuentra en la fase de producción, desarrollo o test.
Cuando algo deba fallar, que lo haga lo antes y más ruidosamente posible, salvo que este en producción, donde debe haber mucho ruido, pero todo lo que pueda seguir funcionando debe hacerlo.
Se debe coordinar la emisión de diferentes tipos de información extraordinaria para cada suceso y segun sea el tipo de trabajo del sistema.
Cuando pueda (email) use el modelo de programación web, investigue AJAX [Garret:ANA-05].
Use en general lenguajes tipo Perl, Python, Ruby, use C3.7 solo para partes muy especiales y luego de prototipar con los anteriores. Solo si es imprescindible use c++, o mono (facilita migración de .net).
Plantee sistemas con códigos en diferentes lenguajes, según sus partes. Use el mejor lenguaje para cada diferente parte de su sistema según convega.
Es mejor mezclar lenguajes que usar un solo lenguaje en áreas para los cuales este es inconveniente.
Use C, cuando no pueda usar Perl, use Perl cuando no pueda usar Bash, Bash cuando Awk no funcione y Awk cuando Sed y otros filtros no puedan hacerlo.
Si Ud. piensa que hay muchas formas hacer lo mismo use Perl [Wall:PP-91] que libera, si cree que hay una forma que es la mejor de todas, use Python [Python:SW] que encasilla. Caos vs. control del pensamiento. O arte creativo vs. ingeniería. La elección es una cuestión de conformación mental de los programadores.
Estudie nuevos entornos de desarrollo como Mozilla [Dumbill:MDP-05], siga con atención a Parrot [Parrot:SW] y Perl6 y estudie los módulos de Apache [Apache:SW].
El 20% de la funcionalidad es el 80% de lo que se necesita.
80% del beneficio viene del 20% del trabajo.
Evite hackear a mano, escriba programas que escriban programas en cuanto lugar pueda.
Prototipe antes de pulir. Hágalo trabajar antes de optimizar. Optimize cuando ya tenga toda la funcionalidad operativa.
Se debe tener el mas simple diseño que ejecute la funcionalidad operativa. A medida que se hay mas funciones se cambia el diseño.
Los programadores restructuran el sistema sin cambiar el comportamiento: para remover duplicación, mejorar comunicaciones, simplificar o flexibilizar.
No temer al refactoreo. Estos trabajos aumentan la flexibilidad del código.
Obliga a codificar en forma comprensible y elegante. Evita concentrase en los detalles. Los refactoreos de los proyectos son su principal activador y cuestionador externo.
Redactar rápidamente una función hasta que opere en su nivel mínimo y luego replantearla para un esquema más complejo o más abstracto.
Diseñe para el futuro, en forma extensible, porque esta mas cerca de lo creíble, pero no se pierda en modelos muy abstractos cuando no los necesita. Pase los test primero, luego abstraiga y generalice el código.
El trabajo de diseño se expresa constantemente en el refactoreo del código. Si es importante, se debe refinar la arquitectura permanentemente.
Mientras mas funciones se construyen mas complejo se hace el código. Pero a medida que se comprende mejor un sistema para una funcionalidad dada, se puede simplificar mediante abstracciones. Es un proceso constante de expansión - compresión.
El cambio permanente y rápido es un muy buen amigo de la programación.
Los cambios se hacen como si se estuviese conduciendo un automovil. Se debe ir llevando el sistema al objetivo poco a poco. Manteniendo su funcionamiento, mediante micro cambios, que aplicados varios en forma consecutiva producen los grandes cambios. El sistema se mantiene siempre en producción con realimentación permanente.
El mejor sistema es el que se esta usando. El software rápidamente debe entrar en producción y mantenimiento. Un sistema que no esta en producción es una carga económica y una ineficiencia.
Los sistemas siempre evolucionan, si se quedan mueren. Un software vivo es aquel que tiene programadores mejorándolo inmersos en su propia cultura. Jugar y explorar.
Ponga un sistema simple en producción rápidamente, luego largue nuevas versiones cada poco.
Realimentación rápida, cambios incrementales con pequeñas diferencias, que puedan evaluarse con facilidad.
Publicación temprana y test inmediato con los usuarios, ciclo corto de desarrollo.
El programa y su diseño evoluciona, los cambios no se restringen a un área, los programadores añaden valor al análisis, diseño, instrumentación, y test. Añaden valor a todos los lugares donde es necesario.
Minimizar el costo de cambiar, para cambiar mucho
Se deben sacar nuevas versiones constantemente. Tiempos de minutos y horas en entre versiones de producción. No semanas o meses. Tener los mecanismos aceitados para poder publicar e instalar nuevas versiones es básico. Si un usuario requiere un cambio y se lo puede poner en minutos mejor.
Código pensado para tener excelencia operacional, gratificación instantánea y no quedar atrapado en tecnologías sin salida.
En este modelo de desarrollo el concepto de producir pequeños cambios y que estos sean operativos y ``gratificantes'' en forma inmediata es fundamental. Libere código pronto y en forma frecuente.
Se debe crear software concreto, intuitivo, fácil de bajar, instrumentary administrar, asumiendo la simplicidad como valor.
Mantenga el código claro y simple.
Transparencia: diseñar para la visibilidad, para hacer la inspección mas fácil.
Robustez: es la hija de la transparencia y la simplicidad.
Modularidad: partes simples conectadas con interfaces claras.
Composición: programas diseñados para conectarse a otros.
Tan simple como sea posible en cada momento. La complejidad extra es removida apenas se la encuentra.
Deben estudiarse y conocer las herramientas e ideas preexistentes. Antes de comenzar se investiga que existe.
Consultar software y proyectos preexistentes, relativos a la tarea a asumir, encontrar un vocabulario y un kit de herramientas y abrir las especificaciones al equipo de desarrollo.
Si lo que se quiere hacer existe, se lo usa o se lo mejora. Si el proyecto es novedoso no se encontrara nada apropiado, pero si es un proyecto cuya idea esta madura, seguramente se encontrarán las capas de abstracción inmediatas sobre las cuales construirlo.
Integrar el sistema muchas veces por día, cada vez que se completa una tarea. Testear apenas integrado.
Pequeñas herramientas para cada tarea, que funcionan desde linea de comando. Separar GUI (Interfaz gráfica de usuario) de herramientas. La herramienta ideal es el filtro.
Lo pequeño es bonito. Escriba cosas chicas y consistentes que cumplan su función.
Todo lo que pueda ser un filtro debe serlo.
Un filtro es un progama cuya única vía de comunicación con el mundo consiste en ``cañerias'' de entrada y salida, y se limita a producir salida en función de lo que va recibiendo en su entrada.
Cuando filtre, nunca tire información que no necesite tirar.
Los ``streams'' de datos deben ser textuales
Donde sea posible, las estructuras de datos deben ser textuales, legibles y editables por humanos
Las interfaces al usuario deben ser separadas de los ``back ends'' complejos
Para diseñar una interfaz al usuario, esta hará lo menos sorprendente.
Utilice interfaces claras entre el código y los datos. Un lenguaje de alto nivel para administrar los datos o bases (SQL). Cuidado con la programación orientada a objetos. Usela sólo en los casos en que realmente sea apropiado.
Repositorios centrales para aplicaciones dispersas. No salirse del estándar, todo debe funcionar con todos los motores sin mas esfuerzos.
Representación, use datos inteligentes, para que la lógica del código sea estúpida y robusta.
Un viejo aforismo dice ``dame la estructura de datos y te daré el código''. Las estructuras de datos inteligentes asociadas a un código torpe funcionan mucho mejor que la alternativa opuesta. ``Enséñame tu código y mantén ocultas tus estructuras de datos, y me seguirás engañando. Muéstrame tus estructuras de datos y normalmente no necesitaré que me enseñes tu código: resultará evidente.'' [Brooks] 3.8
Separar la política de los mecanismos. Pensar delicadamente la interfase de los motores internos.
Un sistema orientado a procesos mostrará las opciones al usuario según los procesos en marcha y las responsabilidades o atribuciones del rol representado por ese usuario.
En estos esquemas la gestión se organiza en procesos. Los procesos representan conjuntos secuenciados de tareas. Las tareas se ejecutan mediante páginas o pantallas. Para cada proceso se registran las tareas cumplidas exitosamente. Los elementos (archivos, directorios, tablas, etc) son los datos. Los roles se implementan por alias o grupos. Los ACL (listas de control de acceso) vinculan roles con permisos y elementos (datos).
Utilice sistemas de control de acceso en sus políticas de seguridad y visibilidad.
Cada sección de código se escribe mediante dos programadores trabajando juntos en cada máquina, todo el tiempo. Ver Programación Extrema: [XP:SW,Robles:IS-02,Robles:PES-02].
Los pares revisan permanentemente el código de otros.
Los usuarios revisan el programa en forma permanente y constante.
La rotación de las personas sobre diferentes partes del código es positiva.
No mas de 40 horas por semana. Nunca sobretiempo u horas extra.
Son las personas que a titulo individual o trabajando para una tercera organizacion: empresa o cooperativa crean material para algun proyecto
Cada persona y organizacion debe registrarse y enviar un compromiso de transferencia de copyright de codigo
La organizacion en ese acto se compromete a mantener el codigo bajo la GPL.
La persona debe informar claramente que no esta en dependencia laboral de una tercera o si lo esta los responsables legales de tal organizacion deben autorizar o firmar el acuerdo.
La organización podra tener a su personal o a personal contratado a ese efecto participando en el desarrollo, este personal tendra un nomina mensual, por lo que no recibiran un aporte especifico por sus aportes, pero estos seran evaluados con la misma rigurosidad por el integrador.
Cada proyecto tiene un integrador, personal de la organizacion o bajo contrato especifico.
Este integrador decide que porcion de codigo, documentacion o codigo de tests ofrecida por los redactores puede integrarse.
En el software libre se acostumbra a publicar rapido, muchas veces y porciones chicas de codigo, no funciona de otra forma pues si mucha gente trabaja y se reciben grandes aportes todos juntos, el trabajo que otros hacen es muy dificil de integrar.
Este integrador puede publicar necesidades orientativas para los que busquen aportar codigo
El integrador podra tener un equipo de personas evaluando las contribuciones y puliendolas en lo que sea necesario. Este equipo estara empleado o bajo contratro en la organizcion.
Es la persona que promueve las vinculaciones entre el proyecto y la comunidad
Sea en proyectos propios o de terceros, en proyectos pequeños puede ser el mismo integrador.
Una vez que a una persona se le acepta el codigo en el proyecto, se mide con determinada metrica prefijada su aporte y se le paga.
La unidad de contrataciones puede asignar algunas necesidades a redactores especificos e incluso prenegociar el precio de tal trabajo
El ciclo de desarrollo de estos modelos colaborativos implican gran velocidad de cambios, estos cambios incluyen a los usuarios, que pueden pedir un cambio y lo tienen operativo en días.
Manejo de la cartera de proyectos propios.
Se aplica cuando no se encuentran equipos que esten desarrollando un software que pueda utilizarse para la tarea en cuestion o cuando se decida que conviene emprender un nuevo proyecto.
Existirá un único repositorio general de la Organización manejado o controlado desde uno de sus laboratorios.
Para cada proyecto su integrador decidira quienes tiene derecho de ``commit''. Todos tendrán derecho de bajar.
Cada proyecto sera asignado a un integrador bajo las siguientes condiciones:
Se aplica cuando se encuentra un software libre util preexistente y un equipo de desarrollo operativo. En este caso la organizacion se suma a un esfuerzo ya existente.
En tal sentido hay que analizar como funciona el proyecto, cuales son las mejores formas de cooperar y que cosas se necesita agregar a las funcionalidades, documentacion, tests, etc de ese software.
Hay tres acciones que probablemente sean utiles en este sentido:
Si en el algun momento el integrador rechaza codigo que la organizacion necesita, se puede poner un integrador interno que mantenga un proyecto paralelo que puede compartir con terceros, (un fork)
Los desarrolladores que pretendan remuneracion por sus aportes a estos proyectos se anotarán en un registro especial comun a todos los proyectos. Exisitra una lista de correo de anuncios para todos ellos.
Una vez que un desarrollador tiene su código aceptado en un proyecto podra reclamar el pago, sea que haya prepactado su trabajo o no.
Existira un tablón de anuncios con todos los requerimientos de la Organizacion en todos los proyectos, propios o no. (podra incluir valor o no).
Los desarrolladores podran acordar y tomar alguno de ellos o resolverlo y luego solicitar pago.
| proyecto propio | proyecto preexistente | |
| Unidad de contrataciones | UNICA | UNICA |
| Integrador | PROPIO, uno por proyecto | no, lo aporta el proyecto |
| Responsable Institucional | UNICO Optativo, promueve la participacion de terceros | UNICO, PROPIO, interactua con el proyecto |
| Redactores | PROPIOS y de terceros | PROPIOS y preexistentes en el proyecto |
Entonces tenemos en la organizacion una unidad de contratciones UNICA (con su equipo), un responsable institucional, con su equipo de personas distribuido por proyectos, y un integrador por proyecto. En cada proyecto habra un responsable de proyecto en la organizacion, que puede jugar el rol de integrador o de responsable institucional o ambos si se lo requiere o tener en pryectos grandes personas con esos roles.
| COORD | LABS | RES. INST. | U.CONTR. | redactores | |
| central | * | * | * | * | |
| por negocios/regiones | * | * | * | * | |
| por area tematica | * | analistas/diseño | |||
| Proyectos | * | Integrador | * | internos externos libres ext. contr. prev |
En los laboratorios por negocio existiran analistas y diseñadores que dividiran el trabajo a realizar en proyectos, detectaran las necesidades y mantendran la coherencia de estilo y el uso de modelos de datos y desarrollo coherentes, tendran relacion directa con los resposables de los proyecto y sus integradores cuando sean diferentes, mantendran el linea entre si a los diferentes proyectos en las areas de integracion.
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Cada camino elejido para un proyecto puede cumplir determinado porcentaje de la meta. Se puede decir que emular en terminal remota es un avance del 5%, un 60% a la liberación de la aplicación, un 20% a la liberación del software auxiliar, y un 25% al funcionamiento en Sistema Operativo libre.
Los interpretes, servidores como apache, bases de datos, compiladores necesarios para la ejecucion y creacion del software se consideran como un bloque.
En particular una lista técnica de correo electrónico para la migración. Una de las acciones para migrar las herramientas de trabajo grupal del equipo de migración. Preparar sitio web y repartir información y claves.