pypyme-giotto — Lista de desarrollo para el sub-proyecto 'Giotto' (estándares,elem. comunes,...)

[Jose F. <coo...@py...>]

Hola a todos,

Como 'maestro de ceremonias' 8-) me gustar=EDa daros la bienvenida a este=
=20
proyecto que espero cumpla las espectativas que hay=E1is puesto en =E9l.

Los primeros mensajes, me temo, ser=E1n de un considerable tama=F1o pues =
hay=20
muchos temas que tratar y decidir y es m=E1s =E1gil tratarlos todos de go=
lpe=20
que de uno en uno. As=ED que os incluyo una especie de 'orden del dia':

	Presentaciones
	Organizaci=F3n interna
	Organizaci=F3n externa
	Est=E1ndares
		- an=E1lisis
		- dise=F1o
		- desarrollo
		- control de calidad
		- documentaci=F3n
		- distribuci=F3n
		- mantenimiento
		- prototipos
		- bases de datos
	Riesgos
	Agenda
	Cierre

1. Presentaciones

	Como ya sab=E9is me llamo Jose Figueras y de alguna forma me encargar=E9=
 de=20
coordinar el proyecto en su conjunto, delegando la coordinaci=F3n de los=20
sub-proyectos en aquellos que lo dese=E9is.

2. Organizaci=F3n interna

	- Antes que nada me gustar=EDa aclarar que todo lo publicado hasta ahora=
=20
acerca de este proyecto trata sobre propuestas. Mi intenci=F3n era sugeri=
r=20
una metodolog=EDa de trabajo que facilitara desarrollar un gran=20
aplicativo. Con esto quiero decir que lo primero que deber=EDamos hacer e=
s=20
decidir si todo lo que est=E1 actualmente propuesto os parece bien o si=20
quer=E9is cambiar alguna cosa (herramientas, formas de documentar,=20
metodolog=EDa,...).

	Las decisiones podr=EDamos tomarlas por mayor=EDa de votos entre los=20
miembros registrados y, en caso de empate, mi voto decidir=EDa.

	Queda pendiente c=F3mo realizar votos, pero eso es algo que ya iremos=20
resolviendo sobre la marcha (se admiten sugerencias).

	- Dada la amplitud del proyecto y la divergencia de intereses de cada=20
uno de nosotros, es l=F3gico que acabemos creando peque=F1os grupos de=20
trabajo (p.e. los que deseen participar en el desarrollo del CRM o los=20
que act=FAen asesorando a los analistas del SCM).

	Como ya habr=E9is observado por la lista de miembros del sitio=20
SourceForge, somos un grupo bastante heterog=E9neo (lo cual est=E1 muy bi=
en)=20
y ya que muchos de vosotros querr=E9is participar en m=E1s de un rol,=20
podr=EDamos crear una matriz de participaci=F3n donde cada uno indique en=
=20
qu=E9 sub-proyecto y bajo qu=E9 papel desea colaborar. La podr=EDamos col=
ocar=20
en la p=E1gina de inicio de la web de desarrollo, en=20
http://dev.pypyme.org/wiki/FrontPage#head-5bb68ad17499b2c517ee5cb932eabbd=
5ff2258fd.

	Esto nos permitir=E1 determinar el orden de desarrollo de los=20
sub-proyectos, qu=E9 partes quedan por cubrir y la composici=F3n de los=20
sub-grupos definidos cuyos miembros han de coordinarse entre s=ED.

	- Ya que utilizaremos listas de correo para comunicarnos, =BFqu=E9 os=20
parece si creamos una par de listas de correo (de desarrollo y de=20
usuario) por cada sub-proyecto (giotto, thalassa, umbriel, oberon, thebe=20
y elara)?. Una alternativa v=E1lida ser=EDa crear listas de correo de=20
desarrollo en SourceForge y montar foros de usuario en la web p=FAblica.

3. Organizaci=F3n externa

	- Actualmente tenemos 3 puntos de contacto con el exterior:
		- la web p=FAblica
		- la web de desarrollo (wiki)
		- el sitio SourceForge

	La web p=FAblica est=E1 pensada para el usuario final. Se trata de un si=
tio=20
donde ofrecer tanto documentaci=F3n de promoci=F3n (tipo 'folleto') como=20
informaci=F3n acerca del estado del proyecto. =BFCre=E9is que vale la pen=
a=20
a=F1adir m=E1s capacidades a este sitio web transform=E1ndolo en un sitio=
=20
comunitario tipo PostNuke o Plone?

	La web de desarrollo utiliza 2 plataformas muy distintas:
		- un sitio SourceForge donde gestionar todos los recursos del proyecto=20
(fuentes, listas de correo, foros de discusi=F3n, etc...), excepto la=20
documentaci=F3n t=E9cnica (y tal vez de usuario)
		- un wiki donde redactar, de forma comunitaria, la documentaci=F3n=20
t=E9cnica y tal vez la de usuario
	=BFOs parece una buena elecci=F3n?

4. Est=E1ndares
	4.1 an=E1lisis (ver http://dev.pypyme.org/wiki/Giotto/Estandares/Analisi=
s)
		- en los documentos incluir:
			Diagrama de contexto
			Casos de uso
			Reglas de negocio
			Matriz de seguimiento
		- utilizando:
			Umbrello UMLModeller
			MoinMoin
		=BFos parece un detalle adecuado?
		=BFprefer=EDs un sistema m=E1s formal o m=E1s informal?

	4.2 dise=F1o (ver http://dev.pypyme.org/wiki/Giotto/Estandares/Disenyo)
		- en los documentos incluir:
			Modelo de datos
			Modelo de objetos
			Interfaz de usuario
		- utilizando:
			Umbrello UMLModeller
			wxGlade 0.3.5.1
			MoinMoin
		=BFos parece un detalle adecuado?
		=BFprefer=EDs un sistema m=E1s formal o m=E1s informal?

	4.3 desarrollo (ver=20
http://dev.pypyme.org/wiki/Giotto/Estandares/Desarrollo)
		- adoptar una arquitectura basada en componentes que se ejecutan en el=20
contexto de un container y cuya estructura interna sigue el patr=F3n MVC=20
'extendido' (donde la funcionalidad de cada componente est=E1 dividida en=
=20
6 grupos: v-vistas, c-controladores, s-servicios, m-modelos,=20
e-entidades, t-tests). Esta forma de plantear el desarrollo tiene sus=20
desventajas: es m=E1s complejo de dise=F1ar y un poco m=E1s complejo de=20
desarrollar, pero tiene varias ventajas: es m=E1s f=E1cil dividir la=20
funcionalidad de forma adecuada, es m=E1s f=E1cil empezar a desarrollarla=
,=20
requiere menos mantenimiento, es mucho m=E1s extensible, configurable y=20
personalizable, facilita la distribuci=F3n y las actualizaciones, etc...

		As=ED que, =BFest=E1is de acuerdo en:
			- desarrollar en base a componentes?
			- dividir la funcionalidad de cada componente en esos 6 grupos?
			- utilizar un container?

		- usar interfaces Python. Mi intenci=F3n original era utilizarlos=20
simplemente como documentaci=F3n (al decir 'class Factura(IDocumento):'=20
entendemos que una factura es un tipo de documento) pero introduce una=20
complejidad que, al final, no creo necesaria. =BFOpin=E1is tambi=E9n que =
es=20
mejor no utilizar interfaces expl=EDcitos?

		- =BFla estructura de directorios os parece correcta?. En este punto os=
=20
agradecer=EDa que esper=E1seis a que subiese al CVS (el pr=F3ximo lunes o=
=20
martes) el prototipo vertical (o 'guia pr=E1ctica de desarrollo') que=20
estoy a punto de acabar y donde podr=E9is ver en la pr=E1ctica c=F3mo que=
da el=20
=E1rbol de desarrollo

		- para desarrollar, =BFprefer=EDs utilizar espa=F1ol o ingl=E9s? (excep=
to,=20
claro est=E1, el c=F3digo de thalassa, que al tratarse de extensiones a u=
n=20
producto 'ingl=E9s', PyContainer, ser=EDa m=E1s correcto desarrollarlo en=
 este=20
idioma y facilitar as=ED su incorporaci=F3n al producto original)
	=09
		- el soporte RPC o de objetos remotos puede implementarse en XmlRpc=20
(limitado pero trivial) o pyro (completo pero m=E1s complejo). =BFCu=E1l=20
prefer=EDs?. =BFO cre=E9is mejor retrasar esta decisi=F3n?
	=09
		- =BFqu=E9 libreria gr=E1fica prefer=EDs soportar?. =BFwxPython, PyGtk =
o Tk?.=20
Tened en cuenta que m=E1s del 90% de los usuarios lo ser=E1n en Windows, =
no=20
en Linux. Y lo digo porque hay que tener en cuenta c=F3mo 'se ven' estas=20
librer=EDas en dicho sistema operativo

	4.4 control de calidad (ver=20
http://dev.pypyme.org/wiki/Giotto/Estandares/ControlDeCalidad)
		- estar=E1 formado por 3 elementos:
			- metodolog=EDa a adoptar
			- tests
			- informes de control de calidad
		- estar=E1 apoyada por un informe OSMM (Open Source Maturity Model), ta=
l=20
y como pod=E9is ver en=20
http://dev.pypyme.org/wiki/Giotto#head-235f7a13252d8e9ee01e6e49fd39252c19=
0b65b5
		=BFOs parece bien este planteamiento?

	4.5 documentaci=F3n (ver=20
http://dev.pypyme.org/wiki/Giotto/Estandares/Documentacion)
		- t=E9cnica, basada en epydoc. En el prototipo vertical que subir=E9 el=
=20
pr=F3ximo lunes o martes incluir=E9 la documentaci=F3n del API correspond=
iente=20
tal y como la genera epydoc
		- de usuario, =BFqu=E9 herramienta utilizar (OpenOffice, LaTeX, DocBook=
)?
		- =BFos parece bien el =E1rbol de directorios propuesto?

	4.6 distribuci=F3n (ver=20
http://dev.pypyme.org/wiki/Giotto/Estandares/Distribucion)
		- se basar=E1 en la creaci=F3n de 1 fichero zip por cada componente a=20
instalar y de una peque=F1a infraestructura que los gestione. Esta forma=20
facilita el desarrollo y la actualizaci=F3n. =BFOs parece buena idea?
		- la instalaci=F3n de la aplicaci=F3n se realizar=E1 con un paquete=20
distutils y ser=E1 independiente de la instalaci=F3n de la infraestructur=
a
		- si decidimos dar soporte a un proceso de instalaci=F3n completo=20
(aplicaci=F3n + infraestructura), la instalaci=F3n de la infraestructura=20
(Python, PyContainer, drivers de bases de datos, wxPython o PyGtk,...)=20
podr=EDa realizarse tambi=E9n con distutils. =BFOs parece posible y=20
recomendable?. =BFC=F3mo distribuir paquetes m=E1s grandes e independient=
es=20
(PostgreSQL/MySQL/Firebird, wxWidgets/GTK,...)?. Yo creo que ser=EDa mejo=
r=20
montar un CD con los paquetes de instalaci=F3n originales y preparar un=20
documento que explique c=F3mo instalarlos y en qu=E9 orden
		- =BFos parece bien el =E1rbol de directorios propuesto?

	4.7 mantenimiento (ver=20
http://dev.pypyme.org/wiki/Giotto/Estandares/Mantenimiento)
		- aunque SourceForge ofrece herramientas para gestionar incidencias,=20
peticiones de mejora, peticiones de soporte y parches, son algo=20
rudimentarias. =BFOs parecen adecuadas o cre=E9is que ser=EDa mejor utili=
zar=20
alg=FAna otra herramienta (Roundup,...)?

	4.8 prototipos
		- para comprobar si es posible desarrollar la arquitectura propuesta,=20
podr=EDamos crear un prototipo 'vertical' (p.e. un mantenimiento de datos=
)=20
que pusiera a prueba los principales elementos que la forman. Como he=20
dicho en un punto anterior, el pr=F3ximo lunes o martes subir=E9 al CVS u=
n=20
prototipo 'vertical' m=EDnimo (s=F3lo soporta SQLite, no tiene soporte pa=
ra=20
RPCs ni para 'aspectos' de infraestructura) que podr=EDamos ir completand=
o=20
posteriormente (a medida que 'thalassa' vaya incrementando su funcionalid=
ad)

		- para facilitar la comprensi=F3n de lo que se ha de desarrollar, creo=20
que ser=EDa bueno crear lo antes posible (en cuanto los asesores y=20
analistas de una aplicaci=F3n hayan identificado la funcionalidad general=
,=20
o sea, la lista de componentes, que se ha de incorporar y hayan podido=20
describir los modelos de datos) un prototipo horizontal que muestre c=F3m=
o=20
ser=E1 el interfaz de usuario de la aplicaci=F3n (tanto las ventanas como=
=20
los informes y listados)

	4.9 bases de datos
		- la propuesta inicial propon=EDa soportar situaciones extremas:
			- SQLite para bases de datos utilizadas por 1 =FAnico usuario que=20
dispone de un equipo de m=EDnimas prestaciones
			- PostgreSQL para bases de datos que han de soportar un gran n=FAmero=20
de usuarios concurrentes (p.e. 100) y que se instalan en equipos dedicado=
s
		Algunos hab=E9is mostrado inter=E9s en soportar MySQL y otros Firebird.=
=20
=BFCre=E9is interesante soportar todas estas bases de datos o una selecci=
=F3n=20
determinada?. Podemos tener en cuenta que si no utilizamos=20
caracter=EDsticas propias de estas bases de datos puede resultar sencillo=
=20
soportarlas todas (un caso aparte ser=EDa SQLite, que a=FAn no soporta=20
ciertas operaciones SQL comunes, como su autor describe en=20
http://www.sqlite.org/omitted.html).

		- yo preferir=EDa reducir al m=EDnimo las dependencias pero, =BFcre=E9i=
s que=20
ser=EDa bueno utilizar alguna libreria Python para el acceso a datos (tip=
o=20
PDO, PyTables,...) que permita olvidarnos de las diferencias entre las=20
bases de datos a soportar?

5. Riesgos
	Un proyecto de estas caracter=EDsticas se enfrenta a varios riesgos:
		- que haya atra=EDdo menos voluntarios que los que son necesarios para=20
poder llevarlo a cabo
		- que la arquitectura no sea correcta (ver=20
http://dev.pypyme.org/wiki/Giotto#head-731bacbbc332f07329260656382aecbf7e=
3bb175).=20
Si lo es, lo sabremos cuando hayamos acabado la primera aplicaci=F3n (o=20
antes si no lo es).
		- que la metodolog=EDa no sea correcta. Si lo es, lo sabremos cuando=20
hayamos acabado la primera aplicaci=F3n (o antes si no lo es).
		- que no se pueda desarrollar toda la funcionalidad necesaria de=20
'thalassa'
		- que no se pueda resolver adecuadamente la impresi=F3n de listados e=20
informes. Esta es una de las debilidades de Python. =BFSugerencias=20
(reportlab, LaTeX)?
		- que seamos incapaces de crear una metodolog=EDa de control de calidad=
=20
que pueda ser reconocida, aprehendida y valorada por sus destinatarios
		- que el rendimiento sea inadecuado para su uso real

6. Agenda
	Os propongo la siguiente 'agenda de desarrollo':
		1. definir c=F3mo (rol) y d=F3nde (aplicaci=F3n) queremos participar
		2. decidir metodolog=EDas para:
			- an=E1lisis
			- dise=F1o
			- desarrollo
			- control de calidad
			- documentaci=F3n t=E9cnica
			- documentaci=F3n de usuario
			- distribuci=F3n
			- mantenimiento
		3. decidir herramientas para los mismos apartados que los del punto 2
		4. decidir si os parece bien esta 'agenda de desarrollo'
		5. los de QA, independientemente del resto de grupos, empiezan a=20
definir la metodolog=EDa a desarrollar para este proyecto (procesos,=20
documentaci=F3n, plantillas,...)
		6. los analistas de cada aplicaci=F3n, apoyados por los asesores que=20
hayan mostrado inter=E9s en participar en ella, redactan un an=E1lisis=20
'res=FAmen' (la p=E1gina principal de la documentaci=F3n t=E9cnica de una=
=20
aplicaci=F3n, como la de http://dev.pypyme.org/wiki/Umbriel) y dise=F1an =
los=20
modelos de datos de forma que los desarrolladores puedan crear un=20
prototipo horizontal
		7. una vez finalizado el punto 6 los desarrolladores empiezan a crear=20
el prototipo horizontal (s=F3lo las capas v y c para 'navegar' de una=20
ventana a otra) que sirva de apoyo a analistas y de material de=20
referencia a los redactores de documentaci=F3n
		8. en paralelo al punto 7 los analistas, apoyados de nuevo por los=20
asesores, van detallando el an=E1lisis y dise=F1o
		9. una vez finalizado el prototipo horizontal del punto 7, los=20
redactores de documentaci=F3n de usuario empiezan a montar el 'Manual de=20
usuario'
		10. a medida que se completa el an=E1lisis y dise=F1o de un componente =
del=20
punto 8:
			10.1 los desarrolladores inician su implementaci=F3n
			10.2 los de QA dise=F1an los procesos de control de calidad que valide=
n=20
el componente
		11. al finalizar la implementaci=F3n de un componente, los de QA lanzan=
=20
los tests de integraci=F3n y de aceptaci=F3n
		12. al finalizar el desarrollo de una aplicaci=F3n, los desarrolladores=
=20
montan el proceso de distribuci=F3n (instalaci=F3n)
		13. los de QA lanzan los tests de sistema y de aceptaci=F3n
		14. los redactores de documentaci=F3n de usuario crean la 'Guia de=20
instalaci=F3n'
		15. el coordinador de la aplicaci=F3n monta un 'bundle' con el c=F3digo=
 y=20
la documentaci=F3n, lo sube a SourceForge y lo anuncia (al menos) en=20
www.sourceforge.net y en www.pypyme.org
		16. nos vamos de copas a celebrarlo 8-)
	=09
	A lo largo de todo el proceso se va ajustando la documentaci=F3n t=E9cni=
ca,=20
el contenido de la web p=FAblica y la informaci=F3n de SourceForge.

7. Cierre
	Bueno, por fin se acaba este primer 'ladrillazo' 8-)).

	Como seguro que me habr=E9 dejado muchos temas de los que tratar, os=20
agradecer=EDa que vosotros mismos vay=E1is 'llenando huecos'.

	Por cierto, para no agobiarnos mucho con este tipo de cosas, me=20
gustar=EDa que esta primera fase de 'contacto', organizaci=F3n y 'toma de=
=20
decisiones' finalizase lo antes posible.

	Y, como he dicho al inicio de esta larga disertaci=F3n, bienvenidos al=20
proyecto.

Saludos,
Jose