4 Metodologia en Comunidad

Metodologas para desarrollo en comunidad
Jos e Dapena Paz

Metodologas para desarrollo en comunidad p. 1/80
Presentacin
Jos Dapena, ingeniero en informtica por FIC
Socio fundador de Igalia
Miembro del Fisterra Team
Comunicador de software libre
Objetivo
Objetivo: Descripcin de buenas prcticas y
herramientas para el desarrollo de software libre, en
comunidad.
Las buenas prcticas de desarrollo de software son
aquellas que nos llevarn a obtener aplicaciones y
sistemas bien construidos.
Veremos cmo aplicar estas prcticas en el peculiar
desarrollo en comunidad, propio del software libre.
Temas
Introduccin
eXtreme Programming
Proceso de desarrollo
Mtricas
Comunidad
Herramientas
Introduccin
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
Introduccin
Mitos sobre el software libre
Desarrollado por accionados.
Desarrollo hacker, soluciones ad hoc. Ausencia de
metodologa.
El xito es casualidad.
Imposible implantar medidas para control de
calidad.
En resumen, es imposible hacer Ingeniera del
software libre, y productos profesionales.
Cosa de accionados?
Los productos de ms xito del software libre no
se hacen por amor al arte.
Los ncleos de los principales proyectos son
llevados por profesionales, nanciados por
universidades o empresas, y se dedican a ellos a
tiempo completo.
Fundaciones y organizaciones sin nimo de lucro
pueden actuar de mediadoras para mantener y
nanciar los proyectos.
Ejemplos: Apache (IBM, Sun, . . . ), Gnome (Novel,
HP, IBM, Sun, . . . ).
Sin metodologa?
No es casualidad que el software libre incorpore
en multitud de ocasiones construcciones y
arquitecturas propias de la mejor ingeniera del
software.
El desarrollo en comunidad ha permitido que el
software libre incorpore como normales tcnicas y
herramientas metodolgicas hoy altamente
consideradas en las teoras de ingeniera del
software.
Sim metodologa? (2)
El control de versiones, gestin de requisitos,
documentacin y repositorios de incidencias,
patrones de diseo, comunicacin entre
desarrolladores, etc, son habituales en la gran
mayora de proyectos de software libre de xito.
Hay un fuerte componente ad hoc en las
soluciones iniciales, pero las comunidades de
desarrolladores con necesidades heterogneas
consiguen refactorizaciones excelentes.
xito = Suerte?
El xito de un proyecto de software libre se basa
principalmente en conseguir una comunidad activa
de desarrolladores y de usuarios.
Este xito no es casual, y hay mtodos para
facilitar que suceda.
Las tcnicas que facilitan el incremento de la base
de usuarios y desarrolladores son una mezcla de
Marketing y la gestin de una infraestructura
adecuada.
Hay que saber vender el proyecto, y hay que
cuidar a los interesados.
Imposible controlar la calidad?
El hecho es que hay muchsimos proyectos de
software libre que responden mejor a los requisitos
de calidad que productos propietarios validados.
El software libre ha desarrollado tcnicas que
gestionan de forma transparente la calidad, a
travs de gestin de errores, control de versiones,
mtricas, autodocumentacin o pruebas.
En los principales proyectos de software libre
podemos encontrar la implantacin de las mejores
tcnicas de control de calidad.
Hoy hablaremos de. . .
Un enfoque metodolgico para construir software
libre.
Herramientas que ofrece el software libre las
necesidades para gestionar la calidad de sus
proyectos.
Algunas tcnicas para cultivar una comunidad
activa.
Algunas de estas tcnicas se estn aplicando en
el Fisterra Team.
eXtreme Programming
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
Qu es eXtreme Programming?
http://www.extremeprogramming.org
Conjunto de tcnicas y prcticas para desarrollo
de software
Metodologa ligera, trata de buscar mtodos
sencillos de obtener software de calidad
Incide en mejorar la comunicacin con los
usuarios, la retroalimentacin en el proceso.
Cuanto antes haya algo funcionando, mejor. Ya le
iremos aadiendo cosas a medida que hagan
falta.
XP y Software Libre
Coinciden los objetivos a solucionar.
Las soluciones tambin.
La mejora de la comunicacin es una forma
excelente de cuidar a la comunidad de usuarios y
desarrolladores.
Es ms fcil conseguir adeptos cuando hay algo
que usar e instalar. Por tanto, cuanto antes haya
algo funcionando, mejor.
Tcnicas de XP
Cuatro mbitos:
Planicacin
Diseo
Codicacin
Pruebas
Planicacin
Historias de usuarios
Sacar nuevas versiones con frecuencia.
Evolucin por iteraciones
Trabajo en equipo
Historias de usuarios
Descripciones informales de necesidades de
usuarios. Sobre dos o tres frases.
Orientan el proceso de desarrollo, y las pruebas
de aceptacin.
Parecidos a los casos de uso, pero en este caso
no estn atados a establecer interfaces de usuario.
Sacar nuevas versiones con
frecuencia
Crear un plan de versiones. Se encajan las
historias de usuarios en diferentes plazos
temporales.
Se separa la visin de los usuarios de la de los
desarrolladores. Mientras unos jan tiempo para
cada historia, otros establecen las prioridades.
Este plan guiar los objetivos de las iteraciones.
Iteraciones
Proceso iterativo. Objetivo inicial de obtener algo
que haga algo. A partir de ah en sucesivas
iteraciones se van implementando ms y ms
historias de usuarios.
Las historias que se implementan en cada
iteracin se deciden al principio de estas. Se
establecen plazos para realizar cada iteracin, y
se realizan de forma secuencial.
No es recomendable estar pendiente de historias
a implementar en futuras iteraciones. Preocuparse
de cumplir el plan de versiones es la prioridad.
Esto da un mejor soporte al cambio de requisitos
de usuarios.
Trabajo en equipo
Al asignar las tareas de cada historia de usuario,
es recomendable fomentar la movilidad de los
desarrolladores, para mejorar el conocimiento
global del proyecto, y evitar prdidas de
conocimiento.
Combinar a los desarrolladores en diferentes
equipos a lo largo del proyecto, fomenta la
cohesin y el aprendizaje. Esto da tambin mayor
exibilidad al equipo, ya que cualquiera estar
ms preparado para trabajar en otras partes del
proyecto.
Tcnicas para el diseo
Regla KISS
Cuidado con la nomenclatura
No aadir funcionalidades antes de lo planicado.
Refactorizar es ms ecaz
Regla KISS
Keep It Simple, Stupid!
Evita soluciones complejas.
Si hay algo complejo, y puede ser sustituido por
algo simple cubriendo las funcionalidades
necesarias actuales, sustityelo.
Una solucin exactamente tan ecaz como
necesitemos nos ahorrar dicultades en el
mantenimiento.
Nomenclatura
La comunicacin del equipo necesita un
vocabulario comn.
Mantener un adecuado diccionario de datos.
Buscar un espacio de nombres que facilite la
rpida comprensin de los conceptos
involucrados.
Los patrones son una buena estrategia para
facilitar la comunicacin de decisiones tcnicas.
Nada ms all del Plan
El Plan es el Amo.
Solo implementaremos lo que mande el Plan,
NADA ms.
Mejor soporte del cambio de especicaciones.
Mayor enfoque en solucionar correctamente los
objetivos actuales del Plan.
Pero refactoricemos
Cuando encontremos puntos en comn de una
historia con otras implementadas, refactoricemos.
Obtener una solucin comn que cubra ambos
casos, partiendo de la historia ya implementada.
Reducir y simplicar el cdigo, obtener una
solucin ms general a partir de requisitos reales.
Cuidado con la complejidad de la solucin
refactorizada.
Tcnicas de codicacin
El usuario siempre disponible.
Utilizar estndares de codicacin.
Orientacin a pruebas de unidad. Integracin
frecuente.
Programacin en pareja. Propiedad del cdigo
colectiva.
La optimizacin al nal.
Horarios razonables.
Relacin cercana al usuario
Cuanto mejor la comunicacin con el usuario,
mejor.
Si es posible, involucrarlo en todas las etapas de
desarrollo.
En cualquier caso, mejorar la comunicacin.
Mejor saber al momento si estamos haciendo o no
lo que el usuario realmente desea.
Estndares de codicacin
Al comenzar el proyecto, deben decidirse los
estndares de codicacin.
Se establecen los parmetros sobre
documentacin, indentacin, estructura de cdigo,
nombrado y localizacin de cheros, etc.
El objetivo es mejorar la comunicacin y facilidad
de mantenimiento de cdigo por todo el equipo.
Todos los lenguajes y entornos de desarrollo
suelen tener denidos estndares para la
codicacin.
Pruebas de unidad
Todo el cdigo desarrollado debera tener mdulos
de prueba automtica.
Las pruebas de unidad comprueban que mdulos
concretos cumplen las funcionalidades esperadas.
Una posibilidad es desarrollar las pruebas de
unidad antes que el desarrollo. Solo estar
completo cuando pase las pruebas de unidad.
Estn orientadas a las historias de usuario.
Programacin en pareja
Idea polmica
Programar en pareja. Dos personas por cada
ordenador.
Una persona codica, y se enfoca a problemas de
implementacin.
La otra persona mantiene una visin de conjunto.
Facilita la transmisin de conocimiento (modelo
maestro-aprendiz).
La teora dice que es ms ecaz que cada uno
desarrollando de forma individual.
Integracin
El repositorio central siempre compila y cumple
con el conjunto de pruebas de unidad establecido.
Minimiza los efectos laterales.
Integrar con frecuencia. Nunca mantener cambios
durante ms de un da fuera del repositorio.
Cuanto ms se tarde en integrar, ms difcil ser
evitar efectos laterales.
Propiedad colectiva del cdigo
Cualquier miembro del equipo puede aportar
ideas, corregir bugs, o refactorizar cdigo de otros.
Por tanto, nadie ser un cuello de botella para
introducir nuevos cambios.
La integracin continua y las pruebas de unidad
facilitan que cualquiera pueda tocar cualquier
parte del cdigo.
Funciona as: un programador desarrolla un
mdulo con sus pruebas de unidad. Otro si aade
funcionalidades, sabr si sigue funcionando el
mdulo porque pasa las pruebas de unidad.
Pasa de la optimizacin. . . por ahora
La optimizacin debe estar guiada por objetivos.
Por tanto, trabajar en optimizar es tirar el tiempo si
no es necesario.
Primero hay que cumplir con los objetivos
previstos
No intentes adivinar dnde estn los cuellos de
botella. Mdelo!
Haz que funcione, hazlo bien, y slo entonces,
haz que sea rpido.
No te pases de las horas
Las horas extra minan la motivacin de un grupo.
Perjudican de forma considerable el rendimiento.
Los proyectos que requieren horas extra para ser
acabados, requerirn prcticamente el mismo
tiempo adicional en la planicacin.
Es preferible revisar el Plan y los objetivos del
proyecto.
Pruebas
Tcnicas aplicadas para las pruebas.
Pruebas de unidad.
Pruebas de aceptacin.
Pruebas de unidad
Pruebas de caja negra sobre mdulos y funciones
del cdigo.
Deben ser automatizables, por ejemplo, formando
parte del proceso de compilacin.
Verican que un mdulo cumple las
especicaciones previstas.
Un enfoque ms agresivo es crear las pruebas de
unidad antes que el cdigo a probar
(programacin orientada a pruebas).
Pruebas de unidad
Todo el cdigo debe tener sus correspondientes
pruebas de unidad.
El cdigo debe pasar todas sus pruebas de unidad
antes de ser liberado o publicado.
Cuando se encuentra un bug, se hacen pruebas
de unidad adicionales para l.
Pruebas de aceptacin
Las historias de usuarios dan lugar a pruebas de
aceptacin.
Los resultados de estas pruebas deben ser
pblicos. Un mdulo no estar completo mientras
no haya pasado las pruebas de aceptacin.
Son denidos por el usuario o cliente. Pruebas de
caja negra que consisten en la denicin de una
operacin del sistema y un resultado esperado.
El xito de una iteracin se mide por los mdulos
completados, y por tanto, signica haber pasado
un conjunto de pruebas de aceptacin superadas.
XP y Software Libre
Cmo encaja esta metodologa, enfocada a la
relacin de un equipo de desarrolladores con clientes,
en el Software Libre pblico?
Puntos clave:
Dimensin del proyecto
Qu es el cliente?
Dnde entra el voluntariado?
Dimensin del proyecto
XP se aplica a proyectos que involucran a un
equipo de desarrollo medio-grande, y la solucin
no trivial de un problema.
Algunas medidas tienen sentido para proyectos
ms pequeos. Si alguna de las medidas es un
estorbo, scala!
Un umbral mnimo interesante sera sobre 2 o 3
meses persona.
El cliente del software libre
A veces no existe la gura del cliente, ya que son
proyectos orientados a comunidades de usuarios.
Si se quiere industrializar este tipo de desarrollos,
la frmula habitual es la de las fundaciones o
organizaciones sin nimo de lucro, que
representan los intereses de usuarios, y actan
como mediadores y clientes.
Si no existe una gura representativa como
cliente, se recomienda seguir muy de cerca el
inters de los usuarios por ciertos requisitos
(votos, listas de correo, . . . ).
Voluntariado
Una gura fundamental en el software libre es la
del voluntario.
No puede exigirle hacer algo que no le gusta, ni
plazos estrictos salvo que desee comprometerse a
ellos.
Por tanto, las planicaciones no deben contar con
ellos sin su peticin explcita.
Por tanto, el voluntario es un elemento que puede
dar valor adicional a los resultados. As, casi
siempre sumar valor al proyecto, y pocas veces
lo restar.
Temas
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
El proceso de desarrollo
Un ejemplo de proceso de desarrollo:
Captura de requisitos
Arquitectura
Especicacin de casos de uso
Modelos de datos
Diseo de componentes e interfaz
Implementacin
Integracin
Pruebas y despliegue
Captura de requisitos
Se captura y documenta las necesidades del
cliente, as como todo el conocimiento posible
sobre las actividades.
Descripcin no tcnica, pero muy concreta de lo
que se desea implementar.
Es la fuente de las pruebas de aceptacin.
Debe ser aprobado por el cliente y estar
disponible.
Da lugar a las historias de usuario en XP, y a la
descripcin de las pruebas de aceptacin.
Arquitectura
Decisin de la infraestructura tecnolgica que dar
soporte al mdulo.
Debe ser tan compleja como el proyecto requiera,
y no ms.
Decisin cardinal en el proyecto, no es fcil
cambiar sin tirar abajo buena parte del trabajo.
Puede dar lugar a requisitos de desarrollo
adicionales, en los que el cliente ser el equipo
desarrollador.
Especicacin de casos de uso
Dene la interaccin del software con el exterior.
En particular con el usuario.
Tambin debe ser altamente visible por el usuario
o cliente, y fcilmente comprensible.
Una buena idea es que incluya borradores de la
interfaz de usuario.
Se derivan de las historias de usuario. Una
historia da lugar a un conjunto de casos de uso
que lo soportan.
Modelos de datos
Eleccin de un modelo de clases, objetos, tablas
de bases de datos, que soporten los requisitos
funcionales.
Se deben denir los tipos de datos
cuidadosamente para cada historia de usuario, de
forma que encajen en un modelo de datos global.
Los patrones de anlisis de Martin Fowler sealan
algunas estrategias sobre cmo hacer este
modelado de forma ecaz y eciente.
Al acabar este punto, podremos denir con
precisin las pruebas de unidad para nuestro
mdulo.
Diseo de componentes e interfaz
Diseo de los componentes software y la interfaz
de usuario que soportarn las especicaciones.
Las interfaces deben ser diseadas siguiendo
precisin las guas de estilo correspondientes al
entorno que utilicemos (HIG, lnea de comando
GNU, . . . ).
Diseo utilizando patrones de diseo, as como
las guas de diseo de componentes del proyecto
(estructuras de componentes de Fisterra, EJBs en
J2EE, . . . ).
Se pueden disear pruebas de unidad adicionales.
Implementacin
Siguiendo estndares claros de codicacin.
Podemos orientarlos a pruebas de unidad.
Recomendacin: una infraestructura de
integracin contnua, sobre el repositorio del
cdigo.
Integracin
Integracin contnua. Incorporar al sistema de
integracin contnua pruebas de unidad para los
mdulos.
Una correcta gestin de las pruebas de unidad
reducir considerablemente los efectos laterales
de incorporacin de nuevas caractersticas.
Obtenemos una versin instalable y funcional
desde el primer momento. Fundamental para la
comunidad de usuarios, tener algo que tocar y
probar.
Pruebas y despliegue
Las pruebas de unidad reducen de forma drstica
la necesidad de pruebas al nalizar un mdulo.
Es fundamental crear una infraestructura
adecuada para la gestin de incidencias y bugs.
Tambin una infraestructura que permita gestionar
correctamente las instalaciones realizadas
(sistemas de paquetes de las distribuciones por
ejemplo).
El proceso con Software Libre
Facilitar el uso de herramientas que den soporte a
la metodologa.
Establecer pruebas de calidad que comprueben
que nuestros mdulos estn cumpliendo con los
requisitos necesarios.
No podemos exigir a un voluntario cumplir con
todos estos puntos. Pero algunos s (gestin de
bugs, criterios de codicacin, etc). En cualquier
caso deben estar documentados, para reducir la
dicultad de entrada en el proyecto.
La gura del mentor.
Temas
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
Mtricas
Deseamos crear software con alta calidad. La calidad
es bsicamente la reduccin de la probabilidad de
que el software no se comporte como est previsto.
Como tal, la calidad no es medible. Pero la gestin de
la calidad s debe estar basada en medidas objetivas.
Por tanto, lo que haremos ser establecer medidas
del cumplimiento de un conjunto de normas y
parmetros deseables para la obtencin de un
producto de calidad.
Mtricas en el proceso de desarrollo
El proyecto debe denir y documentar una serie de
objetivos y herramientas que mejoren la calidad del
proyecto. El cumplimiento de los objetivos debe ser
medible.
Se puede incorporar al proceso de compilacin e
integracin un conjunto de medidas sobre la calidad
del cdigo y su documentacin. Al sistema de control
de incidencias medidas sobre el tiempo de resolucin
de incidencias, etc.
Las mtricas de calidad deben ser visible, al menos,
para el equipo de desarrollo.
Mtricas sobre el cdigo
Varios ejemplos:
Longitud de lnea media.
Proporcin de comentarios signicativos.
Nmero de mtodos documentados.
Porcentaje de cdigo indentado correctamente.
Cumplimiento de los requisitos de nombrado.
Mtricas sobre los errores
Frecuencia de error por mdulo.
Tiempo de resolucin media de error.
Frecuencia de fallo en integracin contnua.
Mtricas en proyectos de software
libre
La implantacin de mtricas y criterios debe
realizarse por los ncleos de desarrolladores de los
proyectos. Tambin su implantacin.
Una vez liberado a los voluntarios de la implantacin
de los mecanismos necesarios para comprobar la
calidad del proyecto, las mtricas funcionan como
incentivo para que mejoren la calidad de sus
contribuciones.
Tambin facilita la explicacin de decisiones de
rechazo para aceptar contribuciones, cuando el
cdigo no cumple con unos mnimos requisitos.
Temas
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
Comunidad
Debemos cuidar a nuestros desarrolladores y
usuarios.
Para ello, la mejor herramienta es la mejora de la
comunicacin, en ambas direcciones.
Visibilidad del proyecto para el
usuario
Un proyecto no solo debe desarrollarse, si no
tambin parecer que lo hace.
Fundamental informar de forma contnua de qu
se est haciendo, y cmo.
El desarrollo no debe ser annimo. Est hecho por
personas con nombre y apellidos.
Importante publicar plazos para versiones, y
cumplirlos.
Importante lanzar versiones nuevas con
frecuencia. Utilizar todos los medios posibles para
que el usuario se entere.
Visibilidad para el desarrollador
Amplia documentacin de los desarrollos, a nivel
de anlisis, diseo y documentacin de cdigo.
Establecer claramente el proceso para colaborar,
y publicarlo.
No ocultar las discusiones y debates tecnolgicos
sobre el proyecto. Permite adems que entren en
debate.
Escuchemos al usuario
Responder rpido a las preguntas, peticiones,
bugs.
Un usuario olvidado es un usuario perdido, y
adems, cabreado.
Permitir mecanismos cmodos y organizados de
recoger los deseos de usuarios y reportes de
error.
Organizar y priorizar la implementacin de las
tareas de los usuarios. Permitir y facilitar la
nanciacin de la implementacin.
Escuchemos al desarrollador
Incorporar a desarrolladores externos al debate
tecnolgico.
Tener muy en cuenta y en serio las ideas externas.
Dos cabezas piensan mejor que una.
Fomentar el debate, pero tener tacto para evitar
las guerras entre desarrolladores.
Temas
Introduccin
eXtreme Programming
Mtricas
Comunidad
Herramientas
Herramientas
En este apartado describiremos el conjunto de
herramientas que utilizamos en el proyecto Fisterra, y
cmo encajan dentro de las medidas descritas.
Tinderbox (integracin contnua y prueba en entornos
heterogneos), CVS (repositorio de cdigo y gestin
de conguracin), Bugzilla (recepcin de bugs y
solicitudes), tWiki y Docbook (documentacin de
anlisis y diseo), XP tracker (planicacin), Bonsai
(indexacin del cdigo disponible), Test (pruebas de
unidad), Autoconf y Automake (portabilidad y gestin
del rbol de compilacin), Umbrello (diagramas UML),
listas de correo e irc (comunicacin de la comunidad),
web (documentacin general y noticias). . .
CVS
Repositorio de cdigo con control de versiones,
mdulos y ramas.
Almacenamos el cdigo, y documentacin del
proyecto.
Permite llevar la gestin de releases, y de
versiones estables e inestables.
Repositorio centralizado de cdigo, tambin
permite que desarrolladores tengan repositorios
para mdulos sin integrar.
Bugzilla
Base de datos de informes de error, clasicados
por mdulos y diversos criterios de importancia, y
su estado de resolucin.
Existen herramientas integradas para introducir
informes desde las aplicaciones, y un frontal web.
Tambin se puede utilizar para gestionar tareas
pendientes.
Tinderbox
Estructura de clientes y servidores. Los clientes
actualizan, prueban, compilan y obtienen logs del
repositorio CVS en diferentes entornos.
Los servidores recogen los resultados de las
compilaciones de los clientes, y los agregan en
tablas visibles por web.
Desarrollado para el proyecto mozilla.
Podemos incorporar pruebas de unidad o mtricas
en las compilaciones automticas. Nos permite
implantar integracin contnua.
Se integra con bonsai y bugzilla.
tWiki y docbook
Proceso de redaccin de documentacin: primero
en el wiki, despus al estabilizarse se pasa a
docbook.
Un wiki es una buena solucin para la
comparticin de conocimiento. Reduce el escaln
para escribir informacin sobre el desarrollo.
Con docbook tenemos manuales integrables en
mltiples formatos, incluyendo los navegadores de
ayuda de Gnome.
Fundamental documentar y catalogar toda la
informacin posible de desarrollo.
XP tracker
Mdulo para tWiki. Conjunto de plantillas para
realizar el seguimiento de un proyecto XP.
Permite coordinar de forma cmoda grandes
equipos de desarrollo. Reeja y documenta tareas
e iteraciones, pudiendo integrarlo dentro del tWiki
con documentacin de desarrollo general.
Permite realizar seguimientos del estado de
realizacin de diversas tareas, e ir modicando
dinmicamente las iteraciones, de forma cmoda.
Bonsai
Herramienta que explota la informacin del CVS.
Permite realizar consultas sobre las actuaciones
en CVS, alimentando una base de datos con los
logs de los commits.
Permite, por ejemplo, saber qu cambios han sido
realizados por una persona, ver las diferencias
entre varias versiones de un chero, la
responsabilidad de una lnea en particular, . . .
Aplicacin web.
Pruebas de unidad
Se utilizan libreras especiales que crean entornos
de ejecucin aislados.
Para C tenemos Check. Para Java JUnit. Para
Python PyUnit, para C++ cppunit, etc.
Se integran los programas de prueba de
funcionalidad, dentro de la compilacin. As,
fallar la compilacin no solo con incorrecciones
sintcticas, si no funcionales.
Autoconf y Automake
Gestin de conguracin. Congura de forma
automtica qu mdulos se compilan, y si se
cumplen las dependencias necesarias para
hacerlo.
Libtool sirve de apoyo, ocultando la complejidad
del uso de libreras compartidas.
PkgCong tambin simplica el proceso de
enlazado de libreras con dependencias
complejas, incluso sin usar scripts complejos de
compilacin.
Umbrello
Herramienta para realizar diagramas UML.
Soporta un conjunto bastante amplio de
diagramas UML: casos de uso, secuencia, clases,
colaboracin, estados, actividad, componentes y
despliegue.
Tambin soporta generacin de cdigo (en
mltiples lenguajes) e ingeniera inversa (en C++).
Listas de correo e IRC
Es importante responder rpidamente a los
requerimientos de informacin de la comunidad.
Tener listas de correo activas, y responder a las
dudas en IRC da una capacidad muy elevada de
resolver esta necesidad.
Cuidado con los idiomas.
Si es posible y adecuado, mantener logs de las
conversaciones y guardar e indexar las listas de
correo.
La lista de correo es el mecanismo central de
comunicacin dentro del equipo de programacin.
Webs de contenidos
Necesaria una buena presencia web para dar
publicidad al proyecto.
Web viva, mostrando las novedades del estado del
proyecto.
Tiene que ser el punto de introduccin suciente
para poder colaborar con el proyecto o usarlo.
Una buena idea es integrarlo de forma apropiada
con el resto de herramientas web (tinderbox,
bonsai, listas de correo, wiki, . . . ).
Metodologas para desarrollo en comunidad
Jos e Dapena Paz

4 Metodologia en Comunidad

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

4 Metodologia en Comunidad

Caricato da

Copyright:

Formati disponibili

Metodologas para desarrollo en comunidad

Jos e Dapena Paz

Potrebbero piacerti anche